[00:10] redir: chat about cross compiling agents? [00:10] axw: yes please [00:10] HO? [00:10] redir: https://hangouts.google.com/hangouts/_/canonical.com/reed-andrew?authuser=1 [00:11] veebers: thumper: is tab completion with juju-core or qa team? [00:11] it is in core I think but not sure who understands it [00:11] thumper: awesome \o/ [00:12] anastasiamac: I'm not sure how to fix bug 1648063 [00:12] used to mgz, I *think* [00:12] Bug #1648063: kill-controller removes machines from migrated model

[00:12] see? amusement :D [00:13] babbageclunk: does it mean that you know what's going on and just don't have a solution? [00:13] anastasiamac: Oh, hang on - I think I need to try to reproduce it now that a related/intersecting bug is fixed. [00:14] veebers: would have been awesome if we had that functional tests to prove/disaprove it ^^ [00:14] disprove* [00:14] anastasiamac: but I'm a bit worried about how to fix the problem in the general case [00:14] anastasiamac, babbageclunk (mentioned in email just forwarded) Seems I came across another version of that bug (or just an extension). After migration everything seems happy, but when I destroy the origin the units get "Agent lost" [00:14] anastasiamac: ack [00:15] babbageclunk: "worried" is our perpetual state... it's generally good! [00:15] means we care [00:16] anastasiamac: after a migration there might be clients that think they know which machines belong to this controller, and end up killing machines that now belong to the target controller. [00:16] babbageclunk: don't we identify mahcines by which controleer they belong to + machine id (maybe even a model)? [00:16] * anastasiamac can't type today... at all [00:18] anastasiamac: hmm, with tagging? maybe. I'll need to do some experiments. [00:19] ouch, migrating models with cross model relations might be complicated. [00:21] thumper: that migrations bug anastasiamac pointed out is pretty bad, should I pick that up or work on intermittent landing blockers? [00:27] babbageclunk: look at the bad one :) [00:28] thumper: yay [00:28] babbageclunk: the model destruction code in the api server just needs to take migration status into account [00:28] the model may be there still but marked migrated [00:29] the destruction code doesn't check [00:29] that is my working hypothesis === thumper is now known as thumper-dogwalk === babbageclunk is now known as babbageclunk-run [00:54] thumper-dogwalk: did u hear back from larrymi about how custom binary went? m trying to figure out if your change would be of benefit here: https://bugs.launchpad.net/juju/+bug/1655169 [00:54] Bug #1655169: Juju 2.1beta3: Mongo Out Of Memory on bootstrap machine 0 [01:05] bah [01:05] axw: ERROR failed to bootstrap model: cannot use agent built for "arm64" using a machine running on "amd64" [01:06] redir: hrm. what's your bootstrap line? [01:07] juju bootstrap arm64-maas kvm/arm64dev2 --constraints arch=arm64 --metadata-source ~/Sync/juju/arm64-bin/streams < axw [01:09] redir: I think that means it didn't find the tools using --metadata-source [01:09] redir: I'd use --debug to figure out what's going on with agent selection [01:17] yeah that's it found 0 packaged agent binaries [01:17] axw: do I have to do something to tell it to look for devel streams? [01:17] rather than released [01:17] redir: ah yeah probably need to pass --config agent-stream=devel [01:18] or whatever it's called [01:18] but really juju bootstrap --use-this-agen /path/to/jujud would be nic3 [01:18] ahh [01:22] same issue [01:22] if I'm on 16.10 is it looking for 16.04 and missing? [01:22] I wonder [01:24] redir: I *think* u can ask it to look for 16.04... there might b a config option... [01:24] * redir looks for config optiosn [01:30] k, see you tomorrow everyone [01:32] perrito666: o/ [01:53] same problem [01:53] cannot use agent built for "arm64" using a machine running on "amd64" [01:54] I'll have to get back to it tomorrow === thumper-dogwalk is now known as thumper [03:50] man, kill controller -t 0 on lxd is gloriously fast [04:50] anastasiamac: you around? === deanman_ is now known as deanman === jamespag` is now known as jamespage [12:50] anyone know what's going on with this juju build failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju/10005/artifact/artifacts/trusty-err.log [12:50] i've been trying to merge this trivial juju-core change for days now [12:50] and i keep getting failure after failure [12:53] tim was working on it last night iirc [12:55] perrito666: ok, thanks [12:55] perrito666: it's a wonder that anything lands at all... [12:58] this has increased over the last days afaik [12:58] the erroring mean [15:11] bbl lunch [15:21] redir: you around/ [16:05] not yet but will be soon-ish [16:05] what's up natefinch ? [16:06] wondering if you know if kvm containers respect constraints [16:07] natefinch: not positive [16:07] about all [16:07] but disk size, ram, cpus are [16:08] arch isn't [16:08] requires hostarch [16:08] redir: *nod* what happens if you try to deploy a container with RAM=32G on a machine with 16G? [16:08] at this point I am guessing [16:08] redir: it's ok, I can check, just wanted to know if you knew [16:08] kvm fails to start [16:09] I also think it is a problem if you put 4 kvms with 30G disks on a system with a 60GB drive [16:09] it will seems ot work, but run out of disk on the 'host' [16:10] good questions [16:10] bbiab [17:24] natefinch: so the the mem case it defines the domain but cannot start it [17:25] tych0: you around? [17:26] redir: interesting. How does that appear to the end user of Juju? [17:27] natefinch: poorly [17:27] it just doesn't start [17:27] redir: lol, not surprising [17:27] I'll put it on the list of known issues [17:28] after it works on rare arches it shouldn't be too hard to handle and return a useful error [17:29] even easier if go-libvirt grows the API we need [17:30] yeah, the problem I'm looking at is that I'm implementing constraints for LXD, which do the right thing as long as your constraint matches the host machine, but you can set mem=8G for a container on a machine with 4GB, and lxd still happily runs a container [17:31] but it'll obviously only have 4GB of ram available [17:36] that isn't ideal [17:36] I think kvm has that issue with disk [17:37] because they are sparse... so aren't actually too big on creation [17:37] but I haven't tested that [17:37] yet [18:19] voidspace: you still around by any chance? [19:30] bbl [20:17] hi, any approximate release date for 2.1? [20:19] real soon now™ === admcleod_ is now known as admcleod [20:26] bbiab going to run an errand [20:37] thumper: ping? [20:37] ping [20:37] pong [20:37] whatever [20:38] babbageclunk: whazzup? [20:38] thumper: so the instances are being deleted in environ.Destroy() - is there a way to rename the containers? [20:39] environ.Destroy on the controller model? [20:39] or on the hosted model? [20:39] thumper: controller I think [20:39] we need to work out why [20:40] thumper: It's just using prefix matching on the names. [20:40] environ.Destroy *should* only destroy that model's machines [20:40] the prefix match shouldn't match others [20:40] we shouldn't be calling environ.Destroy on migrated models [20:40] thumper: Hmm, true - ok, I added lots of logging, I'll rerun my experiment to see. [20:41] ok [21:09] thumper: again a question about implementing a new cloud provider. Now I'm getting: ERROR cmd supercommand.go:458 failed to bootstrap model: cannot start bootstrap instance: no "xenial" images in us/las with arches [amd64] [21:11] what is wrong here? [21:12] thumper: hey, to make your beginning of day more complicated 1) sorry for making you review a pr that was partly obsoleted but tx for the review it gave me a few pointers, 2) there was some talking thes afternoon in another channel about mongo logs and oplog eating most of the ram on some situations, is that what you where looking at? [21:13] * thumper is otp right now [21:33] perrito666: we need to talk about storage at some stage, do you have much overlap with axw where we can do it all together? [21:33] either that or I could catch you first [21:35] thumper: if you give me 1/2 h we can talk [21:35] then you can talk with axw [21:35] nurfet: not entirely sure where this is failing... is it in the provider code where it is trying to start the instance? [21:35] if so, it will be very provider specific, and how it looks for cloud images in the cloud [21:35] perrito666: talk in 30 minutes? or talk for 30 minutes? === smoser` is now known as smoser [21:43] thumper: we can talk now, sorry I was finishing some house chores [21:43] perrito666: gimmie 30 minutes [21:43] thumper: ack [21:51] thumper: it's failing in the provider code. I am not sure how to link an existing image, for instance xenial, with my provider region "us/las". [21:52] sorry I might be asking well known stuff but I am pretty new to Juju [22:11] anyone around? need a 3rd data-point [22:12] thumper: time is up [22:12] pretty easy ask, and if you help you get 100 internet points! [22:12] katco: I sort of am if is a low attention thing [22:12] perrito666: it is [22:12] shoot [22:12] perrito666: can you build/bootstrap lxd from upstream/2.1-dynamic-bridges ? [22:13] perrito666: looking for binary y/n was successful [22:13] katco: sure, fetching [22:13] perrito666: ta [22:14] * perrito666 builds [22:15] nurfet: you are hitting the very cloud specific bits. There needs to be some way for the provider code to ask the cloud to start particular instance types with a particular OS image [22:15] how those images are identified and mapped is very cloud specific [22:15] perrito666: making hangout [22:50] thumper: that's clear to me but I am concern what info I need to provider/store locally in order for Juju to be able to deploy charms? [22:51] katco: I seem to be sticking around at waiting for ip address for longer than I recall happening on lxd [22:51] nurfet: juju stores info locally about the machine, like the series and instance id [22:52] nurfet: once the machine has been started, it is the juju agent running on that machine that deploys the charm [22:52] redir: ta for trying; that might be because this branch is a bit diverged from recent changes. but it should bootstrap i think [22:52] all the provider code needs to be able to do is to start an instance for a model [22:52] and list instances for that model [22:52] normally there is some tagging of the instances using the model UUID [22:53] if we are just thinking about the first step of the machines, you need to be able to start, stop and list instances for a model [22:53] uuid tagging is the easiest way to get some listing [22:53] that uuid tagging has to be at the cloud provider level [22:53] and not rely on any local storage (meaning user's host machine) [22:54] how that tagging is done is very cloud specific [22:54] nurfet: does that help? [22:55] katco: look at gh:jameinel/juju dynamic-bridges branch [22:55] it have developp merged up to it [22:56] at least as of last week [22:57] redir: cool ty... i think i may have figure out what's going on [22:58] k not bootstrapping here [23:00] redir: ta for starting to tal [23:01] thumper: pretty much. The problems are that my cloud provider doesn't support instance tagging nor instance flavors [23:02] but i think i can get around those weeknesses [23:02] nurfet: does it support any form of persistent disk? [23:02] one way we used to do it before instance tagging [23:02] was a file in presistent storage that had a mapping for us [23:03] thumper: it does support persistent storage i.e. HDD volumes [23:04] nurfet: storage not attached to an instance? [23:09] thumper: the storage must be attached to the instances but that's performed on a remote host [23:10] no any kind of local storage is required [23:13] I trying to find a correlation between my cloud provider images and images published on http://cloud-images.ubuntu.com/releases/ [23:14] I am trying to find a correlation between my cloud provider images and images published on http://cloud-images.ubuntu.com/releases/