[01:55] thumper: turns out overwriting the transport did cause issues as it nuked any alternate protocol handlers already registered [01:55] so i did a quick fix https://codereview.appspot.com/14840043 [01:56] heh [01:56] wallyworld_: how did the tests pass? [01:57] or has the original change not landed [01:57] axw: goose tests passed just fine but juju-core tests failed [01:57] ah right [01:57] this is in goose, got it [01:57] yeah. my original solution worked but roger made me change it [02:01] school run [02:20] thumper: gwacl and gomaasapi - there the req.Close attribute was set instead, as all http requests were dispatched via a helper function [02:21] i used that solution with goose originally, but it was more changes as we use http directly there [02:21] so i needed to add the dispatch helper [02:21] but roger suggested using the keep alive attr instead [02:27] wallyworld_: checked in yet? [02:28] bigjools: nope. but i've already resrved my seats [02:28] wallyworld_: just reserved mine. fucking agent had put me in a bulkhead seat with restricted legroom ... [02:28] i think i got 50 [02:29] from memory [02:29] row 39 [02:29] so i can throw things at your head [02:29] 17A on the la->sfo [02:30] i forget what i got for that one, 8 i think [02:30] we can change at the gate so we can hold hands [02:30] nah, just wait till we drive over the golden gate into the sunset [02:32] wallyworld_: http://tinyurl.com/kj3zltm [02:36] uhm so [02:36] is multi-tenancy supposed to work at this point /w MAAS? [02:37] adam_g: not *quite* there is an sru waiting [02:37] bigjools, bug #? anything in proposed i can test? [02:37] it's all tested [02:38] maas (1.4+bzr1693+dfsg-0ubuntu2.1) saucy-proposed; urgency=low [02:38] ? [02:39] oh that kind of testing [02:39] I don't see that in proposed yet [02:40] hmph still in queue [02:40] * debian/patches/99_fix_juju_multienv_lp1239488: Allows juju to distinguish [02:40] between different environments, actually fixing the MAAS side of multiple [02:40] juju environment support. (LP: #1239488) [02:40] <_mup_> Bug #1239488: [SRU] Juju api client cannot distinguish between environments [02:40] that is the one [02:40] still anything that needs to be fixed on the juju side? [02:40] ah it's in the upload queue [02:41] there was a fix for juju but I don't know its status [02:41] thumper: ? [02:41] landed afaik, but not released yet [02:41] has been landed on 1.16 branch for 1.16.1, but again, don't know the status [02:56] wallyworld_: seems like cartridge razors are ok in hand luggage [02:57] oh, surpirsing [03:16] wallyworld_: it also occurred to me that we ought to go shopping for gadgetry [03:17] well why not [03:18] i don't need anything but need != want :-) [03:19] exactly [03:19] I am sure we can take the mustang via Fry's etc :) [03:20] :) [03:21] * thumper is looking for his US cables [03:46] bigjools: the saucy archives should be updated with the final release by now, right? [03:47] "update-manager -d" shows a splash screen saying it's still a beta release [03:49] wallyworld_: yeah release has happened [03:49] apt-get update should make that go away [03:49] update-manager -d does do an update [03:49] it forces your current release to be up-to-date [04:00] wallyworld_: yes but you're still running with the old update manager at that point [04:01] or potentially older [04:01] i would have thought it would have fetched the latest splash info [04:01] so i just ignore that message? [04:02] yeah [04:02] ok, but i reckon it's a poor user experience. it should show info about the release you are upgrading to, not older info [04:02] yup [04:03] cause i reasonably thought the mirrors i was using hadn't been synced yet [04:03] based on the info on the splash screen [04:07] that's also possible [04:11] so then i switch to the canonical archives and same result [04:18] then we should declare it to be buggered [07:45] morning === TheRealMue is now known as TheMue [08:52] frankban: ping [08:52] TheMue: hey [08:52] frankban: hi [08:52] frankban: based on my first proposal rogpeppe had a good idea for env/switch [08:53] frankban: see the last comment on https://code.launchpad.net/~themue/juju-core/053-env-more-script-friendly/+merge/191640 [08:53] frankban: if that is fine for you too I would change my proposal [08:54] TheMue: so, --raw by default and an error exit code if no default env is configured. totally +1 [08:56] frankban: fine, then I'll note it there and the issue and change it this morning [08:57] TheMue: great, thank you! [08:57] frankban: yw [09:32] rogpeppe: ping [10:17] TheMue: pong [10:17] rogpeppe: ah, hiya [10:17] TheMue: sorry, my IRC client has stopped notifying me when someone mentions my name [10:17] TheMue: it's most annoying [10:17] TheMue: hiya, BTW [10:17] rogpeppe: as you may have seen frankban and I agreed on your proposal [10:17] TheMue: cool [10:18] rogpeppe: one question for "juju env --list" [10:18] rogpeppe: in that way it only lists all names [10:18] rogpeppe: but additionally you can pass a name to switch too [10:19] rogpeppe: how would you act in that case and let the output look like? [10:19] TheMue: i had no idea that "env" was a synonym for "switch" [10:20] rogpeppe: yeah, it is [10:20] TheMue: i think "juju switch --list foo" should probably give an error [10:20] TheMue: at some point in the future, when environments may be held remotely, we could potentially use it to implement search functionality but for now that's not needed. [10:22] rogpeppe: ah, fine, that's my idea too. I dislike the combination of switching and listing in one call [10:22] rogpeppe: it's so "hey, please show me the environments. and by the way you can also switch it" :/ [10:39] TheMue: yeah [10:40] rogpeppe: currently cleaning up the tests, everything simpler now :) [10:46] TheMue: i hoped it might be [10:47] mgz: standup? [10:47] wallyworld_: ^ [10:58] dimitern: you still connected? [11:09] gah! [11:09] my connection died at the hangout exactly as yesterday [11:10] and i can't seem to be able to join again [11:12] hm can't join again? what error? [11:20] * TheMue => lunch [11:22] my machine behaves somewhat erratically perhaps it's time for a reboot [12:01] anyone up for doing a review of this? https://codereview.appspot.com/14619045/ [12:01] dimitern, TheMue, natefinch: ^ [12:01] rogpeppe: sure thing [12:08] rogpeppe: there are some comments about this code being temporary. How temporary is this code? Just want to know so I can dial in the amount of nitpicking ;) [12:08] rogpeppe: (in state/apiserver/common/addresses.go) [12:10] rogpeppe: note, my problem is not with your changes, but some minor stuff with the code that was there that could do with a little cleanup [12:38] hm, didn't log out at home [13:21] sinzui: dude, you indented with tabs! Are you feeling okay? [13:21] Obviously no [13:21] * sinzui will fix that [13:23] sinzui: When using 'find' with wildcards, I think it's best to quote the wildcard. [13:23] abentley, I think I want the scripts to look for credentials and configs in JUJU_HOME. I don't we want to force .juju or $HOME [13:23] abentley, yes, I did that twice, [13:24] sinzui: you missed it in archive_tools and retrieve_packages. [13:24] sinzui: I agree about $JUJU_HOME. [13:25] abentley, The last hours broke my head. I was testing what happens when non-required data is missing in steps and find lots of errors that killed the script [13:25] sinzui: Oh, I see. [13:25] s/find/found/ [13:26] abentley, reassembling with existing tools (no debs) was very bad. I will review the scripts with fresh eyes. Though yours are clearly fresh [13:27] sinzui: It's a shame that s3cmd won't accept environment variables, because I could extend "jnova" to work with all providers and I think that would be neat. [13:28] Anyone know what is going on here? http://pastebin.ubuntu.com/6257151/ [13:32] Ah, fixed it. [13:33] is there any way to get apt-get to downgrade a package to a specific version? [13:34] (still trying to fix my IRC client issue [13:34] ) [13:34] rogpeppe: apt-cache policy [13:34] rogpeppe: Take the earlier version number and: sudo apt-get install =. [13:37] jpds: thanks. hmm, looks like nothing's changed in a while, and there don't seem to be any earlier version numbers. [13:37] % apt-cache showpkg konversation [13:37] Package: konversation [13:37] Versions: [13:37] 1.5~rc1+git20130415-0ubuntu1 (/var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_raring_universe_binary-amd64_Packages) (/var/lib/dpkg/status) [13:37] Description Language: [13:37] File: /var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_raring_universe_binary-amd64_Packages [13:37] MD5: 529965a53c80f878568781c6a205d5f5 [13:37] Description Language: en [13:37] File: /var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_raring_universe_i18n_Translation-en [13:37] MD5: 529965a53c80f878568781c6a205d5f5 [13:37] Reverse Depends: [13:37] konversation:i386,konversation [13:37] kubuntu-full,konversation [13:37] konversation-dbg,konversation 1.5~rc1+git20130415-0ubuntu1 [13:37] konversation-data,konversation 1.3~beta1-2 [13:37] konversation-data,konversation 1.3~beta1-2 [13:38] konversation-data,konversation 1.5~rc1+git20130415-0ubuntu1 [13:38] Dependencies: [13:38] 1.5~rc1+git20130415-0ubuntu1 - kde-runtime (0 (null)) kdepim-runtime (0 (null)) libc6 (2 2.14) libkabc4 (2 4:4.4.3) libkde3support4 (2 4:4.4.3) libkdecore5 (2 4:4.5.85) libkdeui5 (2 4:4.7.0) libkemoticons4 (2 4:4.4.95) libkidletime4 (2 4:4.4.95) libkio5 (2 4:4.5.85) libknotifyconfig4 (2 4:4.4.3) libkparts4 (2 4:4.4.3) libphonon4 (2 4:4.2.0) libqca2 (2 2.0.2) libqt4-dbus (2 4:4.7) libqt4-network (2 4:4.7) libqt4-qt3support (2 4:4.7) libqt4- [13:38] xml (2 4:4.7) libqtcore4 (2 4:4.8.0) libqtgui4 (2 4:4.8.0) libsolid4 (2 4:4.4.3) libstdc++6 (2 4.1.1) phonon (0 (null)) konversation-data (5 1.5~rc1+git20130415-0ubuntu1) konversation:i386 (0 (null)) [13:38] Provides: [13:38] 1.5~rc1+git20130415-0ubuntu1 - irc [13:38] Reverse Provides: [13:38] frick [13:38] http://paste.ubuntu.com/6257210/ [13:38] argh, everything is broken [13:38] policy, not showpkg. [13:38] jpds: sorry, that was just the previous contents of my paste buffer [13:38] jpds: the paste points to the intended thing [13:39] jpds: unfortunately DNS lookups take about 10 seconds on this machine at the moment, so my pastebin script hadn't run quickly enough [13:40] Yeah, so no way to downgrade without going to launchpad and downloading an earlier .deb file. [13:41] jpds: well, the binary hasn't changed in months, so i guess it must be something that's gone wrong somewhere in my machine [13:41] :-( [13:42] i might try reinstalling the app i suppose [13:56] natefinch: could you mention my nickname please? [13:56] or anyone [13:56] rogpeppe: Hi. [13:57] jpds: thanks [13:57] Folks, I'm trying to deploy on openstack and I'm getting this error: error info: {"badRequest": {"message": "Multiple possible networks found, use a Network ID to be more specific.", "code": 400}} [13:57] well bugger me backwards with a spade, it worked [13:57] Where do I specify a network ID? [13:57] jpds: mgz might be a good one to ask [13:58] mgz_: ↑ ? [14:07] * rogpeppe goes for some lunch [14:13] jpds: hm... === gary_poster is now known as gary_poster|away [14:17] mgz_: I do have two networks in openstack, the shared ext_net and my own tenent's one. [14:18] yeah, this is somewhat of a problem if that's an error case, as this is from boot, right? [14:18] does nova boot also complain if you don't specify a network? [14:22] mgz_: Yes, exact same message. === gary_poster|away is now known as gary_poster [14:27] jpds: seems mostly like a nova configuration issue then... [14:27] mgz_: No. [14:27] there's not really anything reasonable juju could do here, the best would be list all networks and arbitrarily select one, which still sucks [14:28] You could specify a network to .juju in the environments. [14:28] yeah, because more manual configuration is exactly what we want [14:28] (that is an option, but it doesn't seem ideal) [14:29] (would much prefer nova having a default network selection) [14:29] mgz_: Well, it's one extra flag to the boot option: http://people.canonical.com/~jpds/nova-boot.png [14:30] Maybe make it part of the imagemetadata.json? [14:31] it's not at all related to images === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [15:03] rogpeppe: after a short discussion we'll roll back to env/switch with flag --raw [15:07] rogpeppe, mgz natefinch did we hard code ubuntu series in Juju? Looks like sync-tools cannot do a release [15:07] ERROR invalid series "trusty" [15:13] yep, we did hard code. [15:24] sinzui: There is a syntax error in "assemble-public-tools": generate_streams does not work, because it does "for $tool in" instead of "for tool in". I do not understand why this syntax error doesn't abort the script. [15:27] abentley, me neither. Just fixed that BTW in my scripts [15:27] abentley, I had to pause to deal with this seen in that very function: https://bugs.launchpad.net/juju-core/+bug/1241666 [15:27] <_mup_> Bug #1241666: Cannot creaste simple streams for Ubuntu trusty series

[15:27] sinzui: Glad you caught that before a release. [15:29] sinzui: Also, I think it's good hygiene to use "set -eu", not just "set -e". It does mean you have to use {$foo:-} in some places where $foo would otherwise suffice. [15:29] abentley, I just pushed my changes minus the JUJU_HOME change we discussed this morning [15:29] abentley, okay [15:29] * sinzui makes juju releasable [15:30] sinzui: I don't see the tool fix in the changes you just pushed. [15:30] bugger, I switched [15:30] abentley, now? revno 2008 [15:31] sinzui: Yes, that's got it. [15:31] sinzui: some of the code updates from distro-info, but the bit that's breaking you may not [15:33] sinzui: I just pushed a tweak to set usage. [15:33] sinzui: the bit you finger in the bug at least does have the update code, are you sure your ubuntu.csv has trusty? [15:34] mgz, it does not, yet [15:34] I got updates 2 hours ago [15:34] so, it's not a juju bug, it's an ubuntu bug :) [15:36] mgz_, logged bug 1241674 for the multiple tenant networks issue jpds described above [15:36] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks [15:36] jamespage: thanks [15:36] we can have a fight as to where the problem actually lies [15:36] lets :) [15:36] :-) [15:36] * jamespage fists up [15:36] lol [15:38] juju really needs some selection criteria for networks if it's going to start explictly passing one in [15:40] sinzui: I'm getting an empty added_tools, which is giving me an empty $tool in the loop, which makes rm unhappy. [15:40] sinzui: http://162.213.35.28/job/juju-core-ci/38/console [15:41] abentley, Must have broken this morning. It was a happy loop lastnight [15:42] sinzui: I'm unfamiliar with that syntax. It concerns me that the loop executes for an empty string. [15:42] mgz, does juju-core have a max line length for go code? I need to tell my editor to STFU [15:43] sinzui: no, we try to keep it sane [15:43] abentley, me too. I think we need to look-before-we-leap. [15:43] but some go syntax stuff doesn't really sit nicely with hard line length limits [15:44] sinzui: Is bash really so bad? normally an empty input array means an each loop gets skipped. [15:44] I still aim for less than 80, but with tabs and some function definitions you pretty much always end up going over that as wrapping would be worse [15:44] abentley, I thought the same. Have I mentioned I hate bash today? [15:45] right, I'm transfering back home again, will look at any pending reviews when I'm in [15:45] mgz. okay. I will set no max length, and let common sense rule [15:45] thanks mgz [15:46] bugger! I've got mgo errors again. Since saucy is released I suspect it is me and not the code [15:50] sinzui: Have I mentioned that the heredoc trick works equally well with python? [15:50] abentley, no, but I have used it myself [16:02] TheMue: how come? [16:03] rogpeppe: see discussion on juju-gui [16:05] rogpeppe: oops, just seeing that the proposal is now somehow faulty [16:05] rogpeppe: I've done a revert and then changed the latest whishes [16:06] rogpeppe: now the proposal shows too many files :/ [16:07] rogpeppe: I think I'll simply close this one, take my two changed files and create a new branch :( [16:07] jamespage, do I need to upgrade to trusty to get a /usr/share/distro-info/ubuntu.csv that knows about trusty? [16:07] sinzui, no - that will be SRU'ed [16:07] like right now [16:08] (I see it in -proposed) [16:08] jamespage, fab. I worried I and CI/CD needed to hack that file to do releases [16:18] sinzui: I think I have a fix: http://pastebin.ubuntu.com/6258199/ [16:19] ah [16:19] sinzui: That line noise at 17 is apparently the way you determine the length of the array. So its foo[len(foo)] = bar, or foo.appen(bar) in saner languages. [16:20] +1 abentley [16:21] sinzui: Pushed. [16:43] TheMue: here's probably more appropriate [16:44] TheMue: when you reverted the first time, you reverted the *entire tree* and you'd already merged trunk [16:44] TheMue: so you've manged to revert the changes in trunk that happened since the revision you reverted to [16:48] rogpeppe: oh, now I've seen your reply here [16:52] wow, verifying a public key pair takes 40 *milliseconds* on my machine [16:52] i was wondering why juju switch was so slow, and that's the reason [16:54] rogpeppe: slow? I have no experience to compare. is it done so often? [16:54] mgz: one CL to review => https://codereview.appspot.com/15080044/ [16:54] TheMue: not particularly, but i saw a noticeable delay when running it [16:54] TheMue: it took 0.25s to run on my machine [16:54] rogpeppe: ah, ok [16:54] hey, does anyone have a chance to help paulczar, who is trying to get a charm championship entry finished up, in #juju with what appears to be a juju bug/fragility in https://bugs.launchpad.net/juju-deployer/+bug/1241721 (see comment #2: "agent-state-info: '(error: invalid URL "http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson" not found)'"? [16:54] <_mup_> Bug #1241721: juju-deployer never finishes [16:55] rogpeppe: the CL above is the now fresh and correct one [16:56] so, guys, I'm off now, well see on Monday in SFO [16:56] *wave* [17:03] i'm also off [17:03] g'night all === Makyo|Air is now known as MakyoOnAir [17:28] gary_poster: responded, I suspect just ec2 falkeiness [17:28] *flakiness [17:28] thank you very much mgz [17:28] or something [17:29] yeah, I figured. arguably fragility it would be nice to be able to handle, but probably reasonable to put that off for another day [17:29] yeah, it's hard to see where our robustness is falling down exactly, as we also seem to have not logged the failure from provisioning (assuming there was one) [17:30] mgz, if you have time, can you review https://codereview.appspot.com/15120043 [17:30] sinzui: just saw that looking for TheMue's one :) [17:32] tarty would have been a very silly series name :) [17:33] did I write that again? [17:35] I guess I can expect the same when Unctuous Uakari is not announced [18:02] mgz, is it possible to use the ec2 provider with local simplestream data? ie, against a private openstack via ec2 api? [18:08] adam_g, I don't fully understand your question, but I can confirm that the tools-url has to be to the same cloud. Eg. I cannot set the tools-url to a location I have built test tools, then use them with the cloud I am testing [18:09] adam_g, I have instead uploaded tools and metadata to each cloud, but placed them in a non-standard location and pointed the tools-url to pick them up [18:09] sinzui, tools-url and simplestreams data url are separate, right? [18:10] adam_g, is interested in providing simplestreams data url. [18:10] tools might be an issue too [18:10] im intersted in using juju against a private openstack cloud via the EC2 API, probably with no internet access [18:11] i'd need to specify the AMI ID of the glance image somehow, through a custom simplestream, in the same way i would have done with default-image-id using py juju [18:11] and a custom tools-url, i guess [18:11] smoser, They /might be/. Juju seems to conflate simplestreams with tools. I don't know if it thinks simple streams for images is different for simplestreams for tools [18:12] hmm [18:12] * sinzui looks at old notes [18:13] adam_g, when azure simplestreams was broken in 1.15.0, I could force it to find the correct images doing this: [18:13] image-metadata-url: http://cloud-images.ubuntu.com/releases [18:15] sinzui, so i'd need to somehow fake the streams there for AWS, and point to images in my cloud? [18:17] well. only the client acually *needs* the data. hopefully that can be a url like file:// [18:17] i am pretty sure its checking signatures. [18:17] but maybe any signing key would be ok [18:17] sstream-mirror can allow you to mirror the http://cloud-images.ubuntu.com/releases data to a local directory [18:19] smoser, if only it were that easy.. i need to create a stream of VMDKs :) [18:19] file:/// might work. This bug indicates they do work https://bugs.launchpad.net/juju-core/+bug/1223752 [18:19] <_mup_> Bug #1223752: environs/simplestreams/simplestreams.go leaks test:// and file:// URLs into the http.DefaultClient

[18:20] adam_g, its not significantly more difficult. [18:20] adam_g, for openstack, we actuallydo this. [18:20] on canonistack [18:21] and it supports a "hook" to repack the thing it uplaods [18:21] ie, other than adding glance metadata informtion, i think your use case fits fairly easily into [18:21] http://bazaar.launchpad.net/~smoser/simplestreams/example-sync/view/head:/cstack-mirror [18:22] smoser, unfortunately they cant just be 'repacked' [18:22] sure they can [18:23] smoser, oh? [18:23] what is "repacked" [18:23] converted from a qcow2 image to something that will actually boot on a vmware cluster [18:24] how are you getting what you have? [18:24] ben is using some proprietary tools that come with vmware workstation to convert them on a windows system [18:25] atm i have a single precise vmdk that works, and i'd like to make that available alongside a standard precise image and available to a local cloud via juju [18:27] but jeez, even getting juju to talk to my local cloud endpoints is no longer as trivial as setting them in my environments.yaml :| [18:28] have you tried using vbox convert ? [18:28] do you know that that fails ? [18:31] smoser, no, i haven't [18:33] smoser, i have something that works and would like to make that available to my cloud. i'd prefer not to waste another 4 days wrestling with VMDK images. [18:34] so use the example-sync above, and for "repack" do 'cp some-other-file TARGET-FILE' [18:34] or just hack the glance upload to do nothing [18:34] and just return 'your-uuid-here' [18:38] smoser, are those synced images then available via an EC2 stream as well? [18:39] yes [18:39] what do you mean ec2 ? [18:39] you want image ids ? [18:39] in ami-abcfde format? [18:40] yeah, if he wants to use the ec2 api he'll need that [18:42] you can still specify your own simplestreams stuff with the plugin bits [18:43] smoser, yea [18:44] mgz, the endpoints are contained in some stream data too? [18:45] adam_g, well, then just instead of returnning the uuid return the ami-id [18:45] ami-ids are a PITA [18:45] tahts why they're not implemented in that example-sync [18:45] i really wanted to do it. [18:46] but its difficult because you can't actually say "give me the ami-id for this uuid" anywhere [18:46] youd have to crawl all iamges, and then match on name [18:46] and thats not actually even guaranteed [19:00] Is there documentation on what objects the MaaS API returns? I see docs on calling the REST API endpoints, but not on what they return [19:05] smoser, rvba, anyone else? ^^ [19:05] i dont know about doc [19:28] smoser: you said setting up virtual maas on my local machine was probably a bad idea? [19:30] i would jsut do it on an isntance somewhere [19:31] (ie canonciastack) [19:31] it does all sorts of stuff that i wouldn't want to deal with [19:31] ie, remember how it whacks /etc/resolv.conf ? [19:31] smoser: fair enough [19:31] smoser: right [19:31] this is the juju charm mentality [19:31] just do whatever you want to the root. [19:32] but that doesn't sit so well with "i want my laptop to work" [19:32] heh right [21:40] right, i'm off to bed. taxi arrives in 4 hours. [21:40] see y'all in sf [21:40] natefinch: i'm kinda hoping you might have got something through the post :-)