[00:04] perrito666: yt? [00:04] redir: always [00:04] great [00:05] so looking at bug 1577776 [00:05] Bug #1577776: 2.0b6: asks for domain-name, then doesn't know what it is

[00:05] sorry menn0 wallyworld and I are running over [00:05] * perrito666 clicks [00:05] redir: ok [00:06] You added 'domain-name' to the credential config for opentack [00:06] yes? [00:08] I can add it to the openstack environ schema and provider configurator... but is there more that needs to happen? [00:08] redir: I believe so, for keystone 3 [00:09] Apparently I am getting kicked from the conf room. [00:09] redir: not sure really, the underlying code should be there (I am a bit worried that this bug exists) [00:09] OK. I'll find you later tonight or more likely tomorrow [00:10] perrito666: me too since it seems that something got nuked or was never tested [00:10] bbiab [00:10] or tomorrow [00:10] redir: k [00:16] menn0, are you still available to meet or did you want to skip this week? [00:17] alexisb_: I'm available now. I waited around for a while for you. [00:17] alexisb_: I don't have anything major to discuss except maybe the sprint review workshops. [00:23] menn0, I can join for a bit [00:23] I will hop on [00:23] k, eod, CUALL tomorrow [00:42] bugger [00:42] CreateMutex with a name doesn't give us the semantics we want on windows for the mutex [00:42] * thumper digs some more into windows world [00:48] hmm... [00:48] dog walk time, then I'll try something else [01:06] wallyworld: http://reviews.vapour.ws/r/5072/ -- I'll test with manual now [01:07] ta, looking [01:14] axw: lgtm. works on lxd i assume as well [01:15] wallyworld: will lxd test shortly, pretty certain it will [01:16] yeah, looks like it will [01:36] wallyworld: seems there's a different issue with manual, investigating/fixing in a follow up [01:36] ok [01:36] wallyworld: I'm getting "creating hosted model: model already exists" -- possibly the same thing the grnet folks are getting [01:37] axw: was that grnet issue preceeding this work then? [01:37] wallyworld: the issue the found was before you landed my changes, if that's what you mean [01:37] yeah [01:38] so good to fix [01:38] well I don't know if it's what they're seeing, but need to fix it anyway [01:38] we'll see [01:41] axw: is there a bug number? [01:42] wallyworld: no, it was on the mailing list. about the synnefo provider [01:42] I'll create a bug for the issue I'm seeing now tho [01:42] ok, ta [01:43] wallyworld: actually I suspect it's different, I think it's to do with detecting regions [01:43] rightio. we should maybe test all providers we can to be sure [01:43] cloud says it has no regions, but if you bootstrap manual/ then that goes in as a region [01:44] altho hm I think we add that in.. anyway, I'll look into it and stop guessing [02:06] Bug #1593033 opened: manual: bootstrapping fails with "creating hosted model: model already exists"

[02:33] thumper: simple bit of infrastructure I need for current MM work: http://reviews.vapour.ws/r/5074/ [02:45] wallyworld: http://reviews.vapour.ws/r/5075/ [02:45] looking [02:53] axw: lgtm to but it seems there's a bit of test coverage missing unless i missed it [02:57] wallyworld: yeah, because it's a PITA to inject/test with custom environ providers. I'll see if I can make an incremental improvement... [02:58] axw: we can land for the beta and do in a follow up, let's get the merge happening, so long as you've tested by hand [02:59] axw: also, could you add a few lines to the release notes about this and the cloud/cred/addmodel changes, eg for add model a user visible change is that the --credential argument doesn't take a cloud name prefix anymore [03:02] wallyworld: yep. I'll mention --region, but it's not fully baked yet because you still have to specify region in --config [03:02] wallyworld: on account of us still storing cloud/cred details in model config [03:03] no worries, just the minimal so folks know what to do and are given info on what's different. i have to do a bit on shared config also [03:03] axw: also, when you're free, i have pushed that controller uuid change, but i'll land after the beta revision is finalised [03:04] wallyworld: ok. still gotta look into the CreateModel compatibility [03:04] yep, that takes priority for sure [03:12] wallyworld: bleh, GUI uses ConfigSkeleton [03:12] fark [03:12] we'll have to put it back for now and let them know to remove it [03:12] I guess I'll put it back in, in some minimal form [03:26] fuck yeah!! [03:26] got windows working too [03:26] can't use a mutex because of stupid windows thread bollocks [03:27] if the current thread already owns the mutex, any call to wait for that mutex succeeds [03:27] so I'm using a named semaphore [03:27] with a max count of 1 [03:27] that works [03:27] phew [03:28] wow, that could have been a buzzkill [03:33] Bug #1593042 opened: Juju GUI cannot create new models

[03:39] davecheney: but windows mutex now has exactly the same behaviour as iOS and linux [03:40] I'm busy adding docstrings [03:40] and a few extra tests [03:40] sgtm [03:45] wallyworld: http://reviews.vapour.ws/r/5076/ [03:45] looking [03:49] axw: was hoping it would be simple like that. i did something similar for deploy with adding vs not adding charms [03:55] wallyworld: the existing release notes don't say anything about a cloud prefix on --credential [03:55] well, looks like that omission is now fixed :-) [03:56] wallyworld: on second thoughts, I think we should just be silent about --region until it's fully supported [03:56] ok [04:15] thumper: migration minion now reporting to master: http://reviews.vapour.ws/r/5077/ [04:15] meetingology: ool [04:15] thumper: Error: "ool" is not a valid command. [04:15] oops [04:16] ugh [04:16] meetingology: cool [04:16] thumper: Error: "cool" is not a valid command. [04:16] menn0: cool [04:16] who asked meetingology along anyway [04:16] thumper: it should have been broken up into smaller PRs, but it's not actually that big overall [04:16] thumper: what is meetingology ? [04:16] a bot by the look of it [04:16] I got that :) [04:17] meetingology: help [04:17] menn0: (help [] []) -- This command gives a useful description of what does. is only necessary if the command is in more than one plugin. You may also want to use the 'list' command to list all available plugins and commands. [04:17] meetingology: list [04:17] menn0: Admin, Channel, Config, MeetBot, Misc, NickAuth, NickCapture, Owner, and User [04:17] meetingology: Owner [04:17] menn0: Error: "Owner" is not a valid command. [04:17] meetingology: help Owner [04:17] menn0: Error: There is no command "owner". However, "Owner" is the name of a loaded plugin, and you may be able to find its provided commands using 'list Owner'. [04:17] meetingology: list Owner [04:17] menn0: announce, defaultcapability, defaultplugin, disable, enable, flush, ircquote, load, logmark, quit, reload, reloadlocale, rename, unload, unrename, and upkeep [04:41] davecheney, axw, menn0: https://github.com/juju/mutex/pull/1 [04:42] thumper: will look later. i've got to pick up my daughter from drama class. [04:42] kk [04:43] * davecheney looks [04:43] hey axw - got a sec for a bug question? [04:43] cherylj: yup [04:44] I'm looking at bug 1592887, and the behavior the reporter is describing is what I would expect to happen [04:44] Bug #1592887: juju destroy-service deletes openstack volumes [04:44] wanted to sanity check [04:45] thumper: https://github.com/juju/mutex/blob/192dc9c6d06c8353820d24757b3ed3150ccbae6c/impl_flock.go <-- it's probably a good idea to say in the docs that a name is scoped to user ... but really I don't think we shold do that. that's different behaviour to the other implementations [04:45] thumper: the caller can always put $USER in the name if they want to [04:45] cherylj: looking [04:45] I think that could be fine [04:45] thx [04:46] axw: there is a PR there [04:46] it can have comments :) [04:46] cherylj: expected behaviour. there was always an intention of adding support for disassociating volumes from the lifetime of a service, but never fully implemented [04:47] thanks, axw! [04:51] does anyone know if there's an equivalent json tag for yaml's 'inline'? [04:53] axw, davecheney, menn0: I'll let you argue for a bit about the minor details, but I'm -1 on adding panics [04:53] * thumper is heading to BJJ [05:06] Bug #1592832 changed: enable-ha embeds ModelCommand but should be controller-specific [05:06] Bug #1592887 changed: juju destroy-service deletes openstack volumes === rharper` is now known as rharper [05:15] axw: found another problem if i have a clouds.yam with a custom lxd cloud, validating initialization args: validating cloud credentials: credential "" with auth-type "empty" is not supported (expected one of []) [05:15] le sigh [05:16] wallyworld: we should check for empty AuthTypes list as well as one that includes "empty" [05:16] yeah, that sounds ok doesn't it [05:16] wallyworld: you can have auth-types: ["empty"] [05:16] but we should relax that [05:16] sgtm, cover all cases [05:18] wallyworld: currently knee deep in adding cloud tests, can you please file a bug if you're not looking to fix it [05:18] sure, will probs just chuck up a quick fix [05:19] wallyworld: state/cloudcredentials.go is one place to fix, not sure if there are others [05:19] yup, i'll test manually [06:02] wallyworld: http://reviews.vapour.ws/r/5073/diff/# -- why has bundlechanges changed? [06:03] axw: they merge the service->app rename PR and so we now pull from master and not the feature branch [06:03] same code [06:03] ok [06:07] axw: this fixed immediate issue but now i get a "model already exists" error, need to investigate that http://reviews.vapour.ws/r/5081/ [06:08] wallyworld: failed txn assertion when adding a model [06:08] wallyworld: the error is misleading, basically means the assertions are invalid [06:08] rightio, so fix not perfect :-) [06:08] wallyworld: did you pull master? [06:08] yup [06:10] wallyworld: you need to not add empty to the requiredAuthTypes below [06:10] wallyworld: well really it should be an assertion of len(auth-types)==0 || includes "empty" === cmars` is now known as cmars [06:11] ok, wasn't sure about adding or not [06:11] wallyworld: perhaps it would be simpler if we just require that all clouds have a non-empty AuthTypes [06:11] wallyworld: and when we bootstrap we add []{"empty"] if there's nothing [06:12] that sounds like a bit of a pita when defining clouds [06:12] i'll make this quick fix now and we cn take a view [06:12] wallyworld: no, we'll just add one on the way in [06:12] wallyworld: rather than complicating the assertions everywhere else [06:12] ah, right, i see [06:13] i'll try that [06:47] axw: pushed fix to add auth types at bootstrap, seems to work [06:47] wallyworld: thanks, still going through your other one [06:48] axw: np, sorry, it's large in scope. this other one though is a few lines - i'd like to get it landed asap if possible [06:48] so we can get CI done for release [06:51] wallyworld: reviewed [06:51] (the small one) [06:51] ta [07:05] wallyworld: reviewed the other one too [08:17] axw: thanks for reviews, was otp so missed them. about to head to soccer. the latest commit to master is in CI now (the empty creds one). but the one before which should have had all manual / lxd fixes looks to be failing on manual still http://reports.vapour.ws/releases/4061 [08:18] axw: can you take a look and fix any issue, i'll check back in after soccer; needless to say if there is an issue we need a fix asap [08:36] Hello [08:36] I'm facing a problem. [08:36] 2016-06-16 08:36:27 DEBUG juju.api apiclient.go:500 error dialing "wss://[fd4f:23ae:5d73:5c67:216:3eff:febc:8b38]:17070/model/3923551f-dcf9-4ca8-8b32-dc010722721b/api", will retry: websocket.Dial wss://[fd4f:23ae:5d73:5c67:216:3eff:febc:8b38]:17070/model/3923551f-dcf9-4ca8-8b32-dc010722721b/api: dial tcp [fd4f:23ae:5d73:5c67:216:3eff:febc:8b38]:17070: getsockopt: connection refused [08:37] How to solve this? [08:37] I rebooted my machine many times with no luck [09:07] frobware: dimitern: standup [09:08] Yash: it looks like your machine is trying to reach that host on ipv6 but either the juju server isn't listening on ipv6 or its blocked [09:14] ok [09:14] I disabled ufw [09:15] Is that a problem? [09:15] I pinf ipv6 address but not that port [09:15] nmap failed to connect [09:18] davecheney : Please suggest how to solve? [09:23] wallyworld: the issue is that https://bazaar.launchpad.net/~juju-qa/+junk/cloud-city/view/head:/clouds.yaml contains an entry called "manual" [09:23] which does not have any regions [09:23] wallyworld: it was working before by luck, not by design [09:24] babbageclunk: buy this and I'll buy one (or two) off you http://www.ebay.co.uk/itm/252426716669?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT [09:24] wallyworld: we only do the auto-detect thing if there's no cloud with the given name [09:30] voidspace: They just seem like the ground effect lights that boy-racers put on their car so they can drive around the square in Palmerston North. [09:31] babbageclunk: But for your living room! [09:31] Gah, dumb brain. [09:31] pimping up your living room? :) [09:31] dimitern: exactly [09:32] Yash: What does sudo lxc list show? [09:32] Yash: Does that container have an ipv4 address as well, or just an ipv6 one? [09:36] Something I said? [09:36] maybe he's from palmerston north [09:36] :) [09:37] * babbageclunk lols [09:40] babbageclunk: thanks for that [09:41] admcleod: Well, I don't think I was much help. Hopefully they come back. [09:41] mgz, sinzui, balloons: can one of you please remove the "manual" entry in https://bazaar.launchpad.net/~juju-qa/+junk/cloud-city/view/head:/clouds.yaml -- it's interfering with the ability to use the manual/ syntax in bootstrap [09:45] dimitern, voidspace: Go testing question - when I run go test ./... at the top level, am I right to think that each of the packages' tests are run as separate processes? [09:46] If I did something in juju/testing/mgo.go:init(), it would still run multiple times across the whole test suite. [09:48] babbageclunk: go test ./... just recurses into each subdir, doing the same it does otherwise - i.e. build a .test binary in a subdir then run it [09:48] babbageclunk: how did you get your canonical hostname irc cloak? [09:49] dimitern: Ok, thanks - that's what I thought. [09:50] or, anyone [09:50] admcleod: ? They asked me what irc name I wanted when I was joining. [09:50] hrm ok [09:50] admcleod: Hang on - what do you mean irc cloak? [09:50] admcleod: he's in bluefin, but otherwise do a full-text search on wiki.c.c for "cloak" [09:50] admcleod: there's a separate process for freenode and canonical IIRC [09:51] dimitern: yeah nothing on the wiki that i can find [09:51] babbageclunk: when you whois someone, what should be their hostname/ip address is cloaked/hidden [09:51] https://wiki.canonical.com/StayingInTouch/IRC/FreeNodeRegistration?highlight=%28cloak%29 [09:51] clearly i dont know how to use the search box [09:51] thanks :) [09:51] ;) [09:53] babbageclunk: a cloak can mask your source address for /whois on IRC [09:53] dimitern: oh right. enter does a title search. [09:53] admcleod: I don't think I have one. [09:54] babbageclunk: you do :) all bluefin folk have one by default [09:54] babbageclunk: [babbageclunk] (user@nat/canonical/x-zxxacbyqsikrawst) [09:54] admcleod, dimitern: ah. cool! [10:00] babbageclunk: i believe kjackal may have a question for you also [10:00] hi babbageclunk [10:00] kjackal: hi! [10:00] I am on juju beta8 [10:01] http://pastebin.ubuntu.com/17393462/ [10:01] Deployed a machine (with kafka but that does not matter) and the fqdn is not resolvable/pingable [10:02] is this expected? [10:02] kjackal: What are you deploying to? [10:02] solly yes, lxd [10:02] sorry [10:02] kjackal: realised that after looking at the pastebin, sorry. [10:03] kjackal: nslookup is dns server specific, it doesnt look at /etc/hosts [10:03] admcleod: yes true! [10:04] kjackal: I'm not sure whether we'd expect the container to be resolvable. dimitern? [10:04] Actually! After sometime it gets resolvable and pingable! [10:04] kjackal: What's the broader problem? [10:04] http://pastebin.ubuntu.com/17393499/ [10:05] Yash: welcome back! Did you see my question above? [10:05] So, the fqdn is not resolvable immediately after the container comes up [10:05] babbageclunk: ^ [10:06] kjackal: Sure - but is that actually causing a problem? [10:07] babbageclunk: Yes because if i try to start immediately after I get the machine a service (in my case kafka) it will fail because all the handshakes with other services will fail and in the case of kafka the fqdn is used internaly for figuring out the interfaces to listen to [10:07] no [10:07] kjackal: (I mean, it might be, but I just want to know what the context is - what's the problem you're trying to solve?) [10:08] babbageclunk: Now I cleaning machine. :( [10:08] 10:32 Yash: What does sudo lxc list show? [10:08] > 10:32 Yash: Does that container have an ipv4 address [10:08] Yash: :( [10:09] 10 machines with ip4 and ipv6 ips [10:09] all are running [10:09] kjackal: Ah, ok - thanks [10:09] my exact problem: starting kafka without its fqdn resolvable fails throwing an unknown host exception [10:09] I cann't ssh ubuntu@publicip [10:09] connetion refused [10:10] also I think that if I have two services (eg kafka and zookeeper) trying to comunicate using their fqdns will fail [10:10] babbageclunk: ^ [10:11] kjackal: Sorry, I don't think I'm the right person to answer this (I'm a newbie here). dimitern, any ideas? [10:12] babbageclunk: I appreciate your help [10:13] kjackal: Wish I could be more helpful! [10:20] Yash: so you get connection refused from ssh, rather than permission denied? [10:26] kjackal, babbageclunk: sorry, was afk for a bit [10:27] kjackal, babbageclunk: it looks like either a lxd issue or juju-using-lxd-incorrectly I guess [10:27] kjackal: what's inside /etc/resolv.conf inside the container? [10:28] just a sec [10:28] kjackal: it might be relevant whether this is a trusty or xenial container.. [10:28] Yash: Can you get into the container using "sudo lxc exec -- /bin/bash"? [10:29] dimitern: http://pastebin.ubuntu.com/17393776/ [10:30] kjackal: ok, that looks good - do you have another lxd that cannot resolve itself? [10:30] I have to spin up a new one [10:30] what do you want me to check there? [10:30] the resolv.conf? [10:31] kjackal: yeah, and also pinging e.g. google.com [10:31] dimitern: ^ [10:31] Ok doing it now, will ping you in a moment [10:31] kjackal: btw the /etc/hosts does not have lxd's own hostname.. grr looks like bug 1513165 but on lxd rather than maas [10:31] Bug #1513165: Containers registered with MAAS use wrong name

[10:32] kjackal: just to clarify - what version of juju are you using? [10:32] 2.0-beta8-xenial-amd64 [10:33] kjackal: can you please file a bug like the above, so we can track it separately? [10:34] yes I will do that [10:34] kjackal: please include a paste with /etc/hosts, /etc/resolv.conf, and /etc/network/interfaces, ideally for a container that works ok (like that one above) and a not working one [10:35] kjackal: thank you! [10:35] the ubuntu lxd container came up fine [10:36] kjackal: :/ yeah.. it looks like one of those lxd race conditions.. [10:36] dimitern: here is what I got this time http://pastebin.ubuntu.com/17393827/ [10:36] and is resolvable immediatelly [10:37] cool, let me file this bug and i will try again to repro, to see what the resolv.conf is [10:37] kjackal: ok, try deploying the charm that had the issue I guess? [10:37] kjackal: awesome! thanks, and sorry for the issues :/ [10:37] yes, that is the plan. Do not mention it, this is why we are here for [10:39] kjackal: hey, I've just "groked" your nick btw :) - how's the provider going? [10:39] :) "how is it going" in what sence [10:39] ? [10:40] kjackal: we should try and help you guys with any issues along the way.. it's a bit of a rough path, but you're trailblazers :) [10:40] kjackal: well, I've been looking the ML for progress [10:40] just curious [10:42] dimitern: I am looking at bug https://bugs.launchpad.net/juju-core/+bug/1513165 [10:42] Bug #1513165: Containers registered with MAAS use wrong name

[10:42] in the lxd case both juju-095f51-2.lxd and juju-095f51-2 are resolvable [10:43] dimitern: Should I still open a bug? [10:43] so the dnsmasq instance listening on lxdbr0 is handling DNS requests [10:44] kjackal: yes please, esp. if you find a way to reproduce the issue [10:45] they are both pingable http://pastebin.ubuntu.com/17393893/ but we also need the /etc/hosts to include the fqdn [10:48] kjackal: yeah, sounds like https://bugs.launchpad.net/charms/+source/rabbitmq-server/+bug/1574844 [10:48] Bug #1574844: juju2 gives ipv6 address for one lxd, rabbit doesn't appreciate it.

[10:49] kjackal: not quite, but the same issue - not having the lxd's address and hostname in /etc/hosts [10:50] kjackal: so filing a bug about this will be appreciated! [10:54] here you go dimitern https://bugs.launchpad.net/juju-core/+bug/1593185 [10:54] Bug #1593185: In lxd the containers own fqdn is not inclused in /etc/hosts [10:55] kjackal: thank you! [10:58] dimitern: how is it different from deploying a local charm from fetching it from the store in terms of name resolutions, could this be related [10:58] I deployed my test kafka charm from local and is not resolved... [10:58] kjackal: it shouldn't matter where the charm comes from [10:58] ah wait, I am deploying in trusty series! [10:59] let me try deploying ubuntu from the store trusty series [11:02] I think we have found something dimitern, ubuntu trusty series not resolvable [11:03] kjackal: with a local charm though, you *could* use a similar workaround jamespage did for rabbitmq-server - i.e. update /etc/hosts to include a line with the IP address (returned by `unit-get private-address` in the charm) and the `hostname` (short and fqdn) [11:03] nameserver 10.173.130.1 [11:03] kjackal: no search? [11:03] search lxd [11:04] dimitern: this kind of workaround is not good, because the hostname has to be resolvable by both itself and by others! [11:04] kjackal: what does `nslookup juju-xxx.lxd 10.173.130.1` return? [11:05] http://pastebin.ubuntu.com/17394126/ [11:05] kjackal: and with the .lxd suffix? [11:06] same [11:06] kjackal: odd.. can you ping the dns ip? [11:07] yes 10.173.130.1 is pingable [11:07] kjackal: also, can you paste the output of `ip -d route show` ? [11:08] http://pastebin.ubuntu.com/17394152/ [11:09] kjackal: ok, I suspect there might be a lingering `dhclient` process on eth0 due to /etc/network/interfaces.d/eth0.cfg being present.. [11:09] kjackal: can you please paste /etc/network/interfaces on the container? [11:10] Bug #1593185 opened: In lxd the containers own fqdn is not inclused in /etc/hosts [11:10] Bug #1593188 opened: Include complete information in Client.CharmInfo API call

[11:10] Yes there is a process http://pastebin.ubuntu.com/17394175/ [11:10] dimitern: ^ [11:10] http://pastebin.ubuntu.com/17394184/ [11:11]