=== tasdomas is now known as tasdomas_afk [00:18] davecheney: normally, the name of a compiled Go executable takes after the package directory name. can i change this so that the binary is named something different? eg the directory is "metadata" but I want the binary to be called "juju-metadata" when i do a go install [01:19] wallyworld_: you may have to rename or symlink after the fact maybe? [01:19] thumper: yeah, i was trying to avoid that since most devs just do a "go install" and it will be wrong [01:20] * thumper nods [01:20] package names can't have a - right? [01:20] right :-( [01:20] in which case you are rightly fcuked [01:20] we can add rules to the deb packaging config etc but i want devs to be able to use it easily also [01:20] i can also add a make target [01:21] but most core devs don't like the makefile :-( [01:21] it's all working apart from that [01:24] thumper: what i've done for now is make the package name "jujumetadata" so at least the binary has a reasonable, juju specific name in the default case where no rename is done as part of a local go install [01:25] wallyworld_: yes make a make-target [01:25] wallyworld_: and seems reasonable to have the long package name [01:25] * thumper looks for the default make target [01:25] will do. so between the make target and the juju* package name we should be ok [01:26] make all [01:26] and i'll look into how our release scripts work [01:26] make install maybe [01:26] make install is good i think [01:26] * thumper nods [01:26] there isn't one now [01:26] but should be easy enough [01:26] I will review that change if you like [01:26] I don't mind makefiles :) [01:26] what doesn't allow "-" in the package name? [01:27] Go [01:27] it does [01:27] "." isn't [01:27] it complained when i tried [01:27] let me try again [01:27] ah hang on [01:27] sorry, I'm thinking of commands [01:27] where the packagae name is "main" [01:29] axw: no, you are right. "-" is ok. not sure what i did the first time. thanks :-) [01:29] wallyworld_: nps [01:36] thumper: it seems i need to provide a --description argument to the plugin. what is the intent there? isn't description similar to purpose? or? [01:37] wallyworld_: --description is shown when someone goes "juju help metadata" [01:37] no, that's help isn't it [01:37] yeah [01:37] --description is shown when someone goes "juju help plugins" [01:37] should be a one liner [01:37] yes [01:37] right, but purpose does that doesn't it? [01:37] what purpose? [01:37] ie cmd.Info.Purpose is the one liner [01:38] plugins are defined to be language agnostic [01:38] and entirely unrelated to our cmd stuff [01:39] ok. i'll just make the plugin print Purpose since it's in Go [02:20] Yay! The landing bot is running again then? [02:36] should be [02:39] Oh. But nothing's landed, and all my pending branches failed because the build environment wasn't fully set up. [02:40] Working now. Mine could be the first branches in! [02:49] jtv: you have a merge conflict [02:49] Inevitable. Thanks for the notice. [02:50] But another one got in. Two more to go. [02:51] thumper: oh good, it's all imports! [02:51] Wouldn't it be nice if we could automate that kind of resolution... [02:52] Throw all imports from the conflicting branches together, split them up into the 3 categories and format, try a build, remove any imports that the compiler says aren't needed. [02:59] thumper: i've found an issue with the plugin command. it was incorrectly dropping arguments meant for the plugin. there's a simple one line fix. i'll add a test also [02:59] wallyworld_: you need to pass -- [02:59] to stop the supercommand parsing the extra args [02:59] so [02:59] juju plug -for-juju -- -for-plugin [03:00] hmmm. ok. i did this change [03:00] --- cmd/juju/plugin.go 2013-07-30 01:31:52 +0000 [03:00] +++ cmd/juju/plugin.go 2013-07-30 02:57:22 +0000 [03:00] @@ -26,7 +26,7 @@ [03:00] flags := gnuflag.NewFlagSet(subcommand, gnuflag.ContinueOnError) [03:00] flags.SetOutput(ioutil.Discard) [03:00] wallyworld_: Error: "@" is not a valid command. [03:00] plugin.SetFlags(flags) [03:00] - cmd.ParseArgs(plugin, flags, args) [03:00] + flags.Parse(false, args) [03:00] plugin.Init(flags.Args()) [03:00] schoool run [03:33] afternoon [03:41] thumper: back? [03:41] yep [03:41] just had a coffee :) [03:41] nice [03:42] bigjools: how's tricks? [03:42] thumper: awake, just, but twin1 is home at least [03:42] that must be a relief [03:43] thumper: with my change above, you no longer need the "--". without my change, the user can't run "juju metadata validate-image -r region" unless threy put in the "--" themselves which kinda sucks [03:44] with my change, the args just get flicked through to the plugin to handle [03:44] but plugins are environmental commands [03:44] so -e is valid [03:44] and -e needs to be handled by juju [03:45] to set the environment for the plugin [03:45] sure, -e works for me [03:45] as expected [03:45] -e does what? [03:45] pciks the env to use [03:45] juju metadata -e openstack validate-image -r foo [03:45] works [03:45] the tricky bit is where -e is parsed [03:45] is it parsed by juju [03:45] or the plugin? [03:46] hmmm. i think i made the plugin an env command [03:46] yeah... [03:46] so will need to check [03:46] so this would break other plugins [03:47] I do think the -- is the better solution [03:47] as sucky as it may be [03:47] i'll look into it a bit more. i really don't like the -- for built in plugins that are supposed to look like normal commands [03:49] yeah I know [03:49] but I'm not sure how to handle it better [03:49] without too much manual fuckery [03:50] will probably need work in gnuflag package [03:50] i'm hoping to avoid that [03:50] i'll see if i can insert the -- [03:50] since we are writing the "built in" plugin code [03:54] :) === axw_ is now known as axw [05:11] axw: do you have a gravatar? [05:12] thumper: umm yes [05:12] should be on axwalk@gmail.com [05:12] oh you mean for canonical.com? [05:12] * thumper marvals at the number of errors he just generated [05:12] axw: if you attach your canonical email address to your gravatar, it shows up in leankit [05:13] okey dokey [05:14] BOOM!!!! [05:14] that is what my tests say [05:17] * thumper should really focus on MAAS and not the logging stuff [05:19] OMG we have some awful tests [05:20] thumper: why are you surprised? [05:20] bigjools: I'm not really [05:21] ah so that was more of an Oh Em Gee rather than a OMG [05:23] * thumper nods [05:23] * thumper shelves this work [05:23] it needs more focus [05:23] * thumper goes back to maas [05:27] why does ssh use -p and scp use -P ? [05:27] * thumper pushes 24mb to bigjools [05:28] thumper: thanks a bunch :) [05:28] np [05:28] you have 35G free [05:28] sorry [05:28] 181G free [05:28] only 35 used [05:28] heaps of space [05:29] yeah that machine can be happily destroyed [05:29] I suspect my downlink is better than your uplink [05:30] bigjools: I bet it is too [05:30] 114.6KB/s to push over the ditch [05:33] * thumper bootstraps bigjools's maas [05:34] I always get confused as whether to put the s in 's for something that ends with s [05:34] is there a good rule? [05:34] bigjools: how long until maas realises there is a bootstrap and updates the gui? === tasdomas_afk is now known as tasdomas [05:38] thumper: instant [05:38] but it looks fooked [05:38] it didn't show anything [05:38] yeah not here either [05:38] even though bootstrap supposedly succeeded [05:38] refresh [05:38] ah, there we go [05:39] could be a timeout on rabbit etcetc [05:39] kk [05:39] so now wait 20 minutes? [05:39] yep [05:40] the node powered itself up so should be ok [05:40] you just deployed bare metal from 1500 miles away [05:41] \o/ [05:41] kinda cool [05:41] I'll come back later and poke the running instance === thumper is now known as thumper-afk [06:38] mornin' all === TheMue_ is now known as TheMue [07:39] i'd love a second review of this, please, if anyone wants to have a look. it's very small: https://codereview.appspot.com/12025043/ [07:39] TheMue: ^ [07:41] rogpeppe1: will look in a moment, my vm is just starting ;) [07:42] TheRealMue: thanks === TheRealMue is now known as TheMue [07:44] so I had a branch that failed tests on the bot... due to some missing imports in files I didn't change [07:44] I shouldn't need to manually merge from trunk first right? [07:45] https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849 [07:45] (now I have manually merged, and I need another review...) [07:45] rogpeppe1: could you resend the link pls? [07:45] TheMue: https://codereview.appspot.com/12025043/ [07:45] rogpeppe1: thx [07:46] TheMue: and https://codereview.appspot.com/12038045/ too, if you have a little more time [07:47] TheMue: (i accidentally incorporated the first one into it, so please ignore the upgrader package changes in the second one - they'll disappear when the first one gets merged into trunk) [07:50] rogpeppe1: first review done, looking at the second now ;) [07:51] TheMue: thanks! === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 5 Critical, 80 High - https://bugs.launchpad.net/juju-core/ [07:54] rogpeppe1: do you know what I need to do to make Go Bot happy here? [07:54] https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849/comments/399702 [07:54] axw: looking [07:54] axw: oh yes, it's poxy [07:54] axw: you need to reload the launchpad page before marking it Approved [07:55] axw: i *think* that's probably the reason [07:55] mmkay [07:55] axw: it marks the mp as "approved at this particular revision" [07:55] rogpeppe1: thanks, I'll give it a shot [07:55] ah [07:56] axw: it bites everyone [07:56] do you know why I would've got those test failures in the previous comment? [07:57] I didn't change any of that stuff in my branch [07:57] trunk should always be clean... and there would've been no merge conflicts [08:00] rogpeppe1: review is in [08:00] TheMue: ta! [08:00] axw: i'll have a look [08:01] axw: i've no idea, sorry - i haven't seen anything like that before [08:01] axw: i'd suspect mgz's bot setup [08:01] axw: we'll see if my MP goes in ok [08:02] axw: hmm, mine merged ok, so it looks like the bot *is* working [08:03] rogpeppe1: nps, thanks for checking [08:03] axw: see if it happens again [08:03] rogpeppe1: I already merged manually and pushed, which is the wrong thing to do... I hope that doesn't screw anything up? [08:04] axw: when the bot is working, that is frowned upon [08:04] axw: but given that i'm sure you ran all the tests, it seems reasonable while the bot is flaky [08:05] rogpeppe1: ok, sorry. hopefully it just works next time... [08:05] axw: yeah [08:06] rogpeppe1: when I say I merged manually, I mean I merged trunk into my branch and reapproved my MP [08:06] I didn't push to the trunk directly [08:06] axw: oh, that's standard practice [08:06] rogpeppe1: phew :) [08:13] :) [08:24] fwereade: ping [08:25] fwereade_: ping? [08:34] mgz: morning [08:35] hey thumper! [08:38] thumper, pong [08:38] fwereade_: hey, was thinking we hadn't chatted in a while [08:38] fwereade_: and was wondering if you wanted to catch up [08:41] * thumper sits on the edge of his seat waiting for a response... [08:46] mgz: did you want to catch up since I'm online anyway? [08:46] sure [08:47] mgz: skype, hangout, mumble? [08:48] anything but skype works for me :) [08:48] hangouts on my android phone really sucks the battery [08:48] mgz: so hangout is ok? [08:48] better than mumble normally [08:48] yup [08:57] axw, rogpeppe1: yeah, the bot doesn't want to resolve merge conflicts for you, it's not sentient [08:58] mgz: fair enough ;) where can I see the merge conflicts? [08:58] there weren't any when I did a manual merge [08:58] mgz: ah, that error message didn't look like a merge conflict [09:02] axw: `bzr merge --preview -d trunk mybranch` or similar [09:04] mgz: I already merged from trunk into my branch, and there were no conflicts [09:05] rogpeppe1: fwereade_: i've pushed changes to the validation branch. there's now built in plugin support, with the necessary changes to pass through args and help directives etc. so you can go 'juju help metadata' to get general plugin help listing the supported sub commands and 'juju help metadata validate-image' to get detailed help for that specifc command [09:05] not sure why, but I got this failure: https://code.launchpad.net/~axwalk/juju-core/lp1182898-add-version-flag/+merge/176849/comments/399279 [09:05] (I didn't touch any of those files) [09:05] wallyworld, cool, tyvm [09:06] fwereade_: see what you think. but i'm quite happy with the ui and how it works [09:06] axw: er, sorry, confusing things, looking at the right branch now (it's actually merged now) [09:06] wallyworld: great, thanks [09:07] btw, the binaries just get compiled and put in the normal bin directory [09:07] mgz: I'm not sure if it was necessary, but I merged from trunk after I got that failure, and then pushed back to LP and reapproved the MP [09:08] axw: the message from the bot is complaining that you hit 'approve' in the merge proposal at r1541, then pushed (or launchpad didn't register the push until) the merge of trunk as r1542 [09:08] so, you had an extra rev that wasn't in the change that was 'approved' [09:08] mgz: yep thanks, I understand that last error now [09:08] not really useful in this case as you're self landing [09:09] just not sure why the original test failure occurred [09:09] as there was never a merge conflict AFAICT [09:09] and I didn't change those files [09:09] that mp also has a note from yesterday when the bot was all borked while I was fixing, that can be ignored [09:09] thumper: we probs need to talk to fwereade_ about how/if we should try and record what containers a particular instance supports [09:10] there was a general "don't approve things" in place, but you may not have realised as it was at the end of last week and I didn't restate yesterday [09:10] mgz: okey dokey, sorry about that. I thought it was lifted [09:11] not until 6ish when I sent the email, but apart from confusing you did no harm :) [09:11] ;) cool [09:19] wallyworld: if i type "juju help commands", should i expect to see information on plugins there too? [09:21] rogpeppe1: no. you want to type juju help plugins [09:21] plugins can be bash scripts, python, whatever [09:21] wallyworld: ah, that needs to be documented somewhere [09:22] rogpeppe1: it is isn't it? thumper did all that work [09:22] wallyworld: oh yeah, it is [09:23] wallyworld: hmm, i'm not sure that "juju help topics" should be separate from "juju help" but that's a matter for a different discussion [09:24] wallyworld: BTW i'd expect "juju metadata generate-image --help" to work, but it doesn't [09:26] wallyworld: what does it mean to be a "built-in plugin" [09:26] ? [09:26] wallyworld: i.e. why is the metadata plugin special like that? [09:27] wallyworld__: what was the last thing you saw me say? [09:30] wallyworld__: ping [09:32] rogpeppe1: hi, sorry was washing up after dinner. i saw you say "oh yeah" [09:32] wallyworld__: ah, ok [09:32] [10:23:09] wallyworld: hmm, i'm not sure that "juju help topics" should be separate from "juju help" but that's a matter for a different discussion [09:33] rogpeppe1: juju help topics shows it [09:33] 10:24:03] wallyworld: BTW i'd expect "juju metadata generate-image --help" to work, but it doesn't [09:33] [10:26:23] wallyworld: what does it mean to be a "built-in plugin" [09:33] but the default help should have it shown too [09:33] [10:26:24] ? [09:33] [10:26:49] wallyworld: i.e. why is the metadata plugin special like that? [09:33] thumper: i'd forgotten about help topics [09:33] thumper: would it be unreasonable to merge "help topics" into "help" ? [09:33] rogpeppe1: that shows a bit much [09:34] especially as I'm trying to get more topics [09:34] like constraints [09:34] rogpeppe1: the --help should work i think. i'd been testing with help. plugin arg handling is a little different [09:34] and other... [09:34] rogpeppe1: built in just means it is shipped with juju [09:34] thumper: i wouldn't mind seeing a few more lines in juju help [09:34] out of the box [09:35] wallyworld__: why does "built-in" imply "doesn't allow interspersed flags" ? [09:35] rogpeppe1: I'd ask jcastro and marco what they think [09:35] thumper: +1 [09:36] wallyworld__: also, isn't the very point of a plugin that it's external to the main executable? [09:36] rogpeppe1: because that's what is needed to make the flag handling pass all the args to the next command invoked [09:36] rogpeppe1: it is external [09:36] it's a separate binary [09:37] wallyworld__: so why are built-in plugins special in their flag-handling requirements? [09:37] rogpeppe1: all plugins are [09:38] but external plugins require -- [09:38] and i'd rather make the built in ones look "native" [09:38] and not make the user type "--" [09:39] wallyworld__: that seems like unreasonable special-casing to me [09:39] wallyworld__: a plugin should be a plugin [09:39] wallyworld__: line 30 of https://codereview.appspot.com/11566043/diff/54001/cmd/juju/plugin.go seems weird to me [09:40] i disagree in this case. we don't want the user having to know to type "--" just to use functionality shipped with thr system [09:40] i made it a plugin to get it out of the main juju help topic [09:40] wallyworld__: if we want to make it a plugin, i think it should be a normal plugin. [09:40] i disagree [09:40] wallyworld__: if normal plugins are hard to use, that's another issue [09:40] it needs to be integrated better than that [09:41] wallyworld__: if we want it to be integrated, it should not be a plugin [09:41] wallyworld__: this seems to me to be the worst of both worlds [09:41] well, it was integrated [09:41] wallyworld__: i know, and we decided to make it a plugin [09:41] but then you guys wanted it a little more separated [09:41] wallyworld__: so i think it should be just that. no special casing. [09:41] yes, to uncluter juju help commands [09:41] but i do not want to make it hard for the user [09:42] wallyworld__: this just makes a *third* category of juju subcommand [09:42] users are not unix geeks [09:42] wallyworld__: which actually makes it harder for the user, IMO [09:42] wallyworld__: because they don't know what's going to happen (for example) to the -e flag [09:42] they do [09:42] -e behaves as expected [09:42] it selects an env to use [09:42] wallyworld__: it doesn't for metadata generate-image [09:43] i'd have to check that command, i can't recall if it needs an env or not [09:43] wallyworld__: it takes a -e flag that is *not* an environment [09:44] so that should change perhaps. should -e e reserved across all commands to only mean env? [09:44] be [09:44] wallyworld__: it is reserved in that way for all normal commands (and normal plugins too, i think) [09:44] wallyworld__: except when -- is used [09:45] ok. i'll change that arg name then [09:46] rogpeppe1: actually, that was supposed to be -u for that one [09:46] wallyworld__: i'd be much happier if all the "built-in plugin" stuff was removed too. it's almost self contradictory, and very odd, i think. [09:46] why? i disagree [09:46] wallyworld__: a plug-in is by definition not built-in, i think. [09:47] what? photoshop and other things ship with built in plug ins [09:47] lots of software does [09:47] the plugin mechanism is a framework [09:47] software can ship with built in tools that use the framework. and allow for external extension [09:48] wallyworld__: it seems like we're giving this particular plug-in special privileges because it's awkward to use as a normal plug-in. don't you think that other people providing plug-ins might have similar requirements? but they won't be able to switch on the "built-in" flag. [09:49] wallyworld__: perhaps we should make all plugins parse all their own flags, including -e [09:50] with externally written plugins, my mental model is that they are bolted on type thing. hence one has slightly different expectations [09:50] wallyworld__: how can the user possibly know which things are externally written and which are not? [09:50] the plugins do parse their own flags i think, even the built in ones [09:50] wallyworld__: i don't think they should have to know [09:51] wallyworld__: i think the standard flags are parsed before passing to the plugin [09:51] wallyworld__: and that's why allowIntersperse is true [09:52] wallyworld__: i agree that it's not a great user experience, because they need to know that -e is parsed by juju proper, and the other flags are parsed by the plugin itself [09:52] so the user types "juju help metadata validate-image" and they get told hoe to use the command. they don't really need to know it's a plugin [09:52] wallyworld__: and hence require a "--" separator [09:52] wallyworld__: the juju only *knows* about the metadata command because they typed "juju help plugins" [09:53] yes, that's how you wanted it! [09:53] otherwise i wouldn't have bothered with the work to make it a plugin [09:53] wallyworld__: i defer to fwereade_ [09:54] sorry. discussions on irc suck [09:54] wallyworld__: personally, i was ok with it being either a fully fledged plugin, or a fully builtin (set of) command(s). [09:54] wallyworld__: but this half-way house seems bad to me [09:54] wallyworld__: it's like "it's a plugin but it's not really" [09:55] the only difference i think is the use of "--" or not [09:55] wallyworld__: yes. and without that difference, would you actually *need* the concept of built-in plugins? [09:55] wallyworld__, I suspect rogpeppe1 has a point here, but I'll have to look closer [09:56] as a user, i would HATE to type "--" just to validate some image metdata [09:56] wallyworld__: then as a user you'll hate to use any juju plugin [09:56] wallyworld__: which means that our plugin concept is broken [09:56] maybe. but external ones give different expectations [09:57] built in ones need to be more integrated [09:57] wallyworld__: so let's fix that rather than providing a special-case hack because we don't like the way they work [09:57] since they ship with the system [09:57] wallyworld__: i think all plugins should work well [09:57] good night all [09:57] axw: cheerio [09:57] wallyworld__: and if we can't make the ones that ship with the system work well without special-case hacks, then we're doing something wrong [09:58] why did we force people to use "--" in the first place? was that a limitation of the gnu flags package? [09:58] wallyworld__: i agree with your motivation, BTW. i think it's nasty that the user has to add a "--" to pass flags to a plugin [09:59] wallyworld__: in a way, yes [09:59] wallyworld__: but actually it's a fundamental limitation of the gnu flag syntax [09:59] wallyworld__: you can't parse flags without knowing what flags are expected [10:00] wallyworld__: so what we'd like to do is parse *only* the standard flags and leave the rest for parsing by the plugin [10:00] sounds reasonable [10:00] wallyworld__: but that's impossible in general [10:00] so if we are going to fix the "--" i'd really like to land this as is and follow up separately [10:01] we know if we are processing a "missing command". can't we be less strict on the flags processing in that case [10:01] wallyworld__: i'd much prefer this to land with the command as a normal plugin, without the special-case built-in stuff. it makes the CL more huge than it needs to be [10:01] and just pass what we don;t know about through [10:02] wallyworld__: that's what i was saying - that's actually impossible [10:02] i don't want to impose the "--" on our users [10:02] built in means we get to do a better job of integrating [10:03] wallyworld__: if "better job of integrating" means "we don't need to pass --", and we're planning to fix that, then i don't see the point [10:03] like car accessories or whatever. stuff that comes with the vehicle out of the factory is alsways better than going to the auto shop and bolting on later [10:03] wallyworld__: let's not design it like that, please [10:04] this is about getting much needed functionality into user's hands with the desired interface [10:04] the built in handling is behind the scenes and can be fixed later for any existing plugins [10:04] to remove the "--" [10:04] wallyworld__: the functionality is much more important than the interface at this point [10:05] the ui is important too [10:05] wallyworld__: and this is unnecessary cruft in our code base [10:05] i don't want to ship something only to change the interface latert [10:05] its a few lines to handle tie "--" [10:05] the bulk of the code is business logic [10:06] we need to deliver incrementally [10:06] wallyworld__: speaking of delivering incrementally, that CL should really be split into about 3 or 4. [10:06] wallyworld__: i appreciate that you want to deliver the result though [10:07] it was smallish but then it grew [10:07]