| marcoceppi | Where is the cloud-init file that juju pushes to machines placed? | 00:56 |
|---|---|---|
| === flaviamissi_ is now known as flaviamissi | ||
| axw | marcoceppi: for lxc, /var/lib/juju/containers/<container>/cloud-init | 01:10 |
| marcoceppi | axw: I found them in /var/lib/cloud/seed/nocloud-net, let me check that path too | 01:10 |
| axw | marcoceppi: sorry, I'm looking on the host here | 01:11 |
| marcoceppi | axw: ack, np. Thank for the info! | 01:12 |
| axw | nps | 01:12 |
| === jam1 is now known as jam | ||
| davecheney | can anyone help with a tmux session ? | 06:07 |
| davecheney | question | 06:08 |
| davecheney | using tera term | 06:09 |
| davecheney | the tmux bottom line causes the terminal to scroll one line every second | 06:09 |
| davecheney | any suggestions ? | 06:09 |
| jam | davecheney: futz with $COLUMNS ? | 06:10 |
| davecheney | jam: inside the debug-hook ? | 06:11 |
| jam | davecheney: I don't really know, I would have said trying it in the container before starting the tmux session. It sounds like tera disagrees with 'write to the end of the line' as off-by-one | 06:13 |
| davecheney | jam: yeah | 06:13 |
| jam | which is why some people say you should code to line 79 because sometimes the terminal wraps the final \n. :) | 06:13 |
| davecheney | i don' | 06:13 |
| davecheney | i don't know if its fixable right now | 06:13 |
| davecheney | i might have to twiddle the tmux conf | 06:13 |
| jam | davecheney: can you just use xterm, etc ? | 06:13 |
| davecheney | jam: we are using xterm | 06:14 |
| davecheney | well, tera says it's xterm | 06:14 |
| jam | (10:09:03) davecheney: using tera term | 06:14 |
| jam | davecheney: right, tera is lying and claiming its xterm, but then treating screen width differently (from what you've said at least). | 06:14 |
| davecheney | i've tried vt100 | 06:15 |
| davecheney | vt32 | 06:15 |
| davecheney | vt52 | 06:15 |
| davecheney | etc | 06:15 |
| jam | have you tried a terminal other than tera ? | 06:15 |
| davecheney | jam: not an option sorry, we're in an SOE | 06:15 |
| davecheney | standrard operating environment | 06:15 |
| davecheney | which lacks freedom | 06:15 |
| davecheney | jam: tmux thinks the window is one character larger than it claims | 06:18 |
| davecheney | wider | 06:18 |
| jam | davecheney: my guess is that tmux writes " "*39 + "\r", and tera thinks that the "\r" needs to wrap. | 06:20 |
| jam | I haven't found ways to tweak either tera or tmux in my googling. | 06:20 |
| davecheney | jam: thanks | 06:20 |
| davecheney | let me try one thing | 06:21 |
| jam | Windows shells tend to do the same thing wrong (which is why in our bzr code, we always write to COLUMNS-1, though some terminals let you write all the way to COLUMNS) | 06:21 |
| davecheney | jam: any idea where the default ubuntu branded tmux conf lives ? | 06:23 |
| jam | davecheney: http://askubuntu.com/questions/192401/where-is-the-default-tmux-conf-file-located | 06:23 |
| jam | says there isn't one | 06:24 |
| jam | but there are examples | 06:24 |
| jam | in /usr/share/doc/tmux/examples | 06:24 |
| === tasdomas_afk is now known as tasdomas | ||
| davecheney | jam: where does debug hooks get it's magic one from ? | 06:27 |
| davecheney | is this byobu ? | 06:27 |
| davecheney | ah, it is | 06:28 |
| axw | davecheney: it'll use ~/.tmux.conf if it exists | 06:30 |
| axw | on first execution, that'll get populated with "source /usr/share/byobu/profiles/tmux" | 06:31 |
| axw | source-file.. | 06:31 |
| davecheney | fuck | 06:35 |
| rogpeppe | mornin' all | 08:07 |
| rvba | jam: mgz: Hi… would any of you be available to update gwacl on the landing bot's machine? | 08:45 |
| rogpeppe | fwereade: yo! | 08:46 |
| fwereade | rogpeppe, heyhey | 08:46 |
| rogpeppe | fwereade: how's tricks? | 08:47 |
| fwereade | rogpeppe, not bad, had a lovely peaceful weekend | 08:47 |
| fwereade | rogpeppe, and yourself? | 08:47 |
| rogpeppe | fwereade: i had a lovely weekend full of frenetic outdoor activity :-) | 08:48 |
| rogpeppe | fwereade: and in general things are ok | 08:49 |
| wallyworld_ | jtv: are you working on code to call getImageBaseURLs() on the azure provider? | 08:49 |
| rogpeppe | fwereade: current area of discussion is how we might make the bulk API call code a little less... bulky | 08:50 |
| jtv | wallyworld_: not working on anything in the provider ATM, why? | 08:50 |
| rogpeppe | fwereade: one possible approach is this: https://codereview.appspot.com/12845043 | 08:50 |
| rogpeppe | fwereade: natefinch has another thought, which you might have seen (automatic code generation) | 08:51 |
| jtv | wallyworld_: the simplestreams code is already working for Azure, apart from a few limitations (images for any location only available in West US; only daily saucy images actually functional yet) | 08:52 |
| wallyworld_ | jtv: i'm doing some refactoring to extrude into a common function the url gathering which augments the base url with provider specific ones (if the provider supports such an operation) | 08:52 |
| wallyworld_ | so the azure function can be deleted | 08:52 |
| jtv | wallyworld_: that sounds nice... will it grab both the daily and the released images? | 08:52 |
| wallyworld_ | jtv: the current function just returns the DefaultBaseURL - i wasn't going to change that behaviour | 08:53 |
| wallyworld_ | how is simplestreams working if nothing calls that function? | 08:53 |
| wallyworld_ | for azure | 08:53 |
| jtv | wallyworld_: argh, another piece of dead code then! We just use the same global variable that that function returns. | 08:54 |
| fwereade | rogpeppe, interesting -- it's one of those situations that makes me weep for the lack of generics really | 08:55 |
| jtv | Sometimes I find myself wishing for a tool to warn about dead code in Go. Some kind of lint checker. | 08:55 |
| wallyworld_ | the code should have been calling that function :-) | 08:55 |
| jtv | wallyworld_: feel free to change it! | 08:55 |
| wallyworld_ | ok, i'll work on it, thanks :-) | 08:55 |
| rogpeppe | jtv: there might have been something like that added to go vet recently | 08:55 |
| jtv | rogpeppe: thanks! Worth reading up on then. | 08:56 |
| rvba | wallyworld_: sorry to bother you with that… but do you have access to the landing bot? I need gwacl to be updated there. | 08:56 |
| wallyworld_ | rvba: yes, sure | 08:56 |
| rvba | wallyworld_: thanks a lot. | 08:56 |
| rogpeppe | fwereade: it's this kind of repetition which was the reason i structured the API the way I did in the first place (so that the magic was all in one place, in the rpc package) | 08:57 |
| jtv | rogpeppe: not seeing anything in the godoc for "go vet." There is some stuff that might be nice to make more routinely accessible though. | 08:57 |
| rogpeppe | jtv: on tip? | 08:57 |
| jtv | The PPA. | 08:58 |
| wallyworld_ | rvba: now on rev 217. correct? | 08:58 |
| rogpeppe | jtv: ah, it hasn't even landed on tip yet: https://codereview.appspot.com/12507043/ | 08:58 |
| rvba | wallyworld_: perfect, thanks again. | 08:58 |
| wallyworld_ | np, anytime | 08:59 |
| fwereade | rogpeppe, yeah, I can see that limiting the spread of magic is generally a good thing | 09:00 |
| rogpeppe | jtv: it only works with unexported identifiers though, so i'm not sure if it would flag your case above (what's the dead code you're referring to?) | 09:01 |
| dimitern | fwereade, rogpeppe: fwiw we agreed yesterday to continue with the current approach until we have the uniter talking to the API first, and then proceed to refactor the server-side stuff - as we agree to do it - code generation or reflection | 09:02 |
| jtv | rogpeppe: unused unexported method. But if it's not landed yet, my individual case is sort of moot. :) | 09:03 |
| fwereade | dimitern, that sgtm, thanks | 09:03 |
| fwereade | dimitern, I'm kinda suspicious of both approaches ;p | 09:03 |
| rogpeppe | jtv: you could always apply the CL locally | 09:04 |
| dimitern | fwereade: I have my doubts as well, but the most important thing for me now is not to lose momentum with the implementation | 09:04 |
| fwereade | dimitern, +100 | 09:04 |
| jtv | rogpeppe: to detect a dead method we've already detected? Thanks. :-) | 09:04 |
| rogpeppe | jtv: lol | 09:04 |
| rogpeppe | jtv: but what about all the others we haven't? :-) | 09:05 |
| jtv | Their time will come. | 09:05 |
| fwereade | rogpeppe, does https://bugs.launchpad.net/juju-core/+bug/1205286 ring any bells? | 09:39 |
| _mup_ | Bug #1205286: charm directory permissions now more restrictive <juju-core:New> <postgresql (Juju Charms Collection):Triaged> <postgresql-psql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1205286> | 09:39 |
| rogpeppe | fwereade: not really, but i regularly campaign against the gratuitous use of non-0777 permissions when creating directories, usually to no avail | 09:41 |
| noodles775 | fwereade: I've updated the Makefile to add stable (now that the mongodb deps are there). If you can mark the MP to approved it should land: https://code.launchpad.net/~michael.nelson/juju-core/update-readme/+merge/179165 | 09:42 |
| fwereade | noodles775, thanks, will do | 09:43 |
| noodles775 | ta | 09:43 |
| rogpeppe | fwereade: hmm, a naive grep doesn't show that as a problem here though. | 09:43 |
| fwereade | noodles775, done | 09:43 |
| fwereade | rogpeppe, yeah, I was just poking at it and wondering what the deal was | 09:44 |
| * rogpeppe should really try out the local provider :-) | 09:45 | |
| fwereade | rogpeppe, that said, my instincts are leaning towards the "everything should keep working if everything jujey is removed" | 09:45 |
| fwereade | rogpeppe, which would imply the "feature" interpretation | 09:46 |
| rogpeppe | fwereade: by "everything", you mean the charm? | 09:46 |
| fwereade | rogpeppe, yeah | 09:46 |
| rogpeppe | fwereade: i think it's important that the charm directory be definitively available | 09:46 |
| rogpeppe | fwereade: apart from anything, lots of charms use it to put config file templates in etc | 09:47 |
| fwereade | rogpeppe, templates, fine... they'll only be used by hooks, surely | 09:47 |
| fwereade | rogpeppe, but I'm pretty sure that the charm dir should be considered off-limits to anything not running as a hook | 09:48 |
| rogpeppe | fwereade: hmm, it's certainly arguable | 09:48 |
| fwereade | rogpeppe, because nothing else has any reason to believe that arbitrary changes are not happening at any given time | 09:48 |
| rogpeppe | fwereade: yeah - assuming we overwrite charm dirs rather than duplicate them | 09:49 |
| fwereade | rogpeppe, I think all it takes is assuming that hooks might do anything to the charm dir, and that v1 of a charm can't know what subsequent versions may choose to do instead | 09:50 |
| rogpeppe | fwereade: but i'd like to at least know why we're seeing this behaviour - it doesn't look as if we're deliberately using 700 perms | 09:50 |
| dimitern | rogpeppe, fwereade: https://codereview.appspot.com/12849043 - service-related uniter API calls | 09:50 |
| fwereade | rogpeppe, I agree there | 09:50 |
| rogpeppe | fwereade: personally i think the charm directory should be considered immutable | 09:51 |
| rogpeppe | fwereade: but i realise that's probably a lost battle now | 09:51 |
| fwereade | rogpeppe, one day we'll need some charm format changes, we can force it then, I hope | 09:52 |
| fwereade | rogpeppe, all it really takes is *providing* a directory that charms are expected to write to | 09:53 |
| fwereade | rogpeppe, and then rolling it up with some more changes that are compelling enough to make people want to switch ;p | 09:53 |
| rogpeppe | fwereade: tbh i don't think we'll ever do it - we'd be giving up the main value of juju, which is the large base of charms | 09:53 |
| rogpeppe | fwereade: yeah, we should definitely provide a charm scratch dir | 09:54 |
| rogpeppe | fwereade: we could do that now actually | 09:54 |
| fwereade | rogpeppe, yeah, that sounds smart actually | 09:54 |
| fwereade | rogpeppe, then it's just a matter of communicating it to the charmers, and phasing in requiring its use | 09:55 |
| rogpeppe | fwereade: yeah | 09:55 |
| fwereade | rogpeppe, hard to check for automatically but we can certainly put it on the checklist | 09:55 |
| fwereade | rogpeppe, on the other hand, we do lose the rollbackability | 09:55 |
| fwereade | rogpeppe, however I'm not sure anyone's really using that | 09:55 |
| fwereade | rogpeppe, ...but we don't know | 09:56 |
| rogpeppe | fwereade: rollbackability assumes that *all* state is in the charm dir | 09:56 |
| * rogpeppe likes that word | 09:56 | |
| fwereade | rogpeppe, true | 09:56 |
| fwereade | rogpeppe, or at least it assumes that external state is regenerated from the contents of the charm dir, but yeah | 09:57 |
| rogpeppe | fwereade: anyway, we could theoretically roll back the contents of the scratch dir | 09:58 |
| dimitern | mgz, jam: https://codereview.appspot.com/12849043/ | 09:58 |
| fwereade | rogpeppe, yeah | 09:58 |
| rogpeppe | fwereade: (assuming there are only files in there - what do we do if people are putting unix-domain sockets in there? :-)) | 09:59 |
| rogpeppe | dimitern: i'm looking | 09:59 |
| dimitern | rogpeppe: thanks | 09:59 |
| fwereade | rogpeppe, hunt them for sport? ;p | 09:59 |
| rogpeppe | fwereade: lol | 10:00 |
| jam | fwereade: so did you have a response for bug #1205286 so that stub can get unblocked? | 10:05 |
| _mup_ | Bug #1205286: charm directory permissions now more restrictive <juju-core:New> <postgresql (Juju Charms Collection):Triaged> <postgresql-psql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1205286> | 10:05 |
| jam | fwereade: also, you never commented on Placement Directives and I wanted to send that to the list: https://docs.google.com/a/canonical.com/document/d/1Gq8RKyI4uLSYeamz7C2F0tgXdHhTj-d8thKhyX6ae4c/edit?usp=sharing | 10:10 |
| fwereade | jam, I'm still thinking/trying to figure out what's happened with the bug | 10:10 |
| jam | k | 10:11 |
| jam | I don't have a particular stake in the matter, just care that stub has a way forward | 10:11 |
| jam | and no particular rush on placement directives, but sort of a "lets get docs from the sprint out to everyone lese" | 10:12 |
| fwereade | jam, I've just made the only comment I think I want to on placement directives | 10:19 |
| jam | fwereade: well, if you want to barf on the overlaps, you'd need a way to disable the overlap for the current request (i think) | 10:20 |
| jam | and the MaaS case for tags that might be service level, but might be unit level | 10:21 |
| jam | are a bit less obviously "broken" than zone | 10:21 |
| rogpeppe | dimitern: reviewed | 10:25 |
| dimitern | rogpeppe: cheers | 10:25 |
| dimitern | rogpeppe: LifeGetter works on units, how can it work on services as well? | 10:26 |
| rogpeppe | dimitern: with no problem? | 10:27 |
| dimitern | rogpeppe: with different entities? | 10:27 |
| dimitern | rogpeppe: and we need both Watch for units and services | 10:27 |
| rogpeppe | dimitern: LifeGetter works on any entity that has a Life method | 10:27 |
| dimitern | rogpeppe: we need different methods for watching units and services | 10:28 |
| rogpeppe | dimitern: all you'd need to do is make the auth func return ok for both units and services | 10:28 |
| rogpeppe | dimitern: really? | 10:28 |
| dimitern | rogpeppe: yes | 10:28 |
| rogpeppe | dimitern: don't we watch both units and services with a Watch method? | 10:28 |
| rogpeppe | dimitern: which has the same signature for each | 10:28 |
| dimitern | rogpeppe: why should the same method operate differently? | 10:28 |
| dimitern | rogpeppe: that's mixing responsibilities | 10:29 |
| rogpeppe | dimitern: it's not operating differently - we're passing in entity names to watch, and it's doing that | 10:29 |
| dimitern | rogpeppe: it should work either on units or on services, you can't mix them | 10:29 |
| rogpeppe | dimitern: why not? | 10:29 |
| rogpeppe | dimitern: we're saying "watch these things" | 10:30 |
| rogpeppe | dimitern: where a thing is uniquely identified by its tag | 10:30 |
| dimitern | rogpeppe: how about configsettings then? | 10:30 |
| dimitern | rogpeppe: by your logic we shouldn't need another method | 10:30 |
| rogpeppe | dimitern: we still need an entry point for that | 10:30 |
| rogpeppe | dimitern: because we don't have an entity for config settings | 10:31 |
| rogpeppe | dimitern: we don't consider having a Lifer interface to be mixing responsibilities | 10:31 |
| dimitern | rogpeppe: so you propose to create a different authFunc just for LifeGetter and Watch works on either only units or only services | 10:31 |
| dimitern | rogpeppe: I don't think it should accept mixed units and services tags in one call | 10:32 |
| rogpeppe | dimitern: why not? | 10:32 |
| rogpeppe | dimitern: it's a bulk call | 10:32 |
| dimitern | rogpeppe: because it complicates the tests - we need to test all variations | 10:32 |
| rogpeppe | dimitern: it takes a load of entities | 10:32 |
| rogpeppe | dimitern: it's no more complicated than having extra entry points | 10:33 |
| rogpeppe | dimitern: probably less so | 10:33 |
| rogpeppe | dimitern: and the API calls make more sense that way, i think | 10:33 |
| dimitern | rogpeppe: no, the simplification for having a single entry point will be transfered to increasing the test size 4-fold | 10:34 |
| rogpeppe | dimitern: why should the API provide both UnitLife and ServiceLife when a single Life entry point is sufficient? | 10:34 |
| rogpeppe | dimitern: really? isn't it a single extra entry in the argument slice? | 10:34 |
| dimitern | rogpeppe: and we're talking about both Watch and Life - so AgentEntityWatcher and LifeGetter both need to work on units and/or services | 10:35 |
| rogpeppe | dimitern: isn't that trivial? we just make an auth function that allows both the unit or the unit's service | 10:35 |
| dimitern | rogpeppe: no, each tests tests at least 3 cases: valid tag, invalid tag, valid but unauthorized tag | 10:35 |
| rogpeppe | dimitern: so that's 2 more entries in the arg slice, no? | 10:36 |
| dimitern | rogpeppe: when we take into account services and units can be passed, that comes to 6 cases | 10:36 |
| dimitern | rogpeppe: and in addition, we need to add a case when the tag is neither service nor unit | 10:37 |
| dimitern | rogpeppe: so that's 7 cases to test | 10:37 |
| dimitern | rogpeppe: i agree they can be done in a single call | 10:37 |
| dimitern | rogpeppe: just the testing logic will be a bit more complicated after we get the results and check the resources | 10:38 |
| rogpeppe | dimitern: yes, you'll have some extra cases to check, but you'd need to check all those cases if you had a different API call, no? | 10:39 |
| dimitern | rogpeppe: and when relations come into play, I suppose their Life will be using the same entry point, so that's 3 more cases | 10:39 |
| rogpeppe | dimitern: sure - but isn't it great that we can use the same API call (and code) for getting the Life of any entity? | 10:39 |
| rogpeppe | dimitern: doesn't that make it particularly nice that we are actually sending tags over the wire, rather than just ids? | 10:40 |
| dimitern | rogpeppe: I'll think about it a bit | 10:40 |
| rogpeppe | dimitern: we already have the LifeGetter implementation, which can be used for all of this | 10:40 |
| jam | rogpeppe: so I think they may end up in different facades, and the different facade may need to restrict what they are allowed to look at. But as long as the Auth is valid (unit agents can't look at machines, for example) having a unified call sounds good. | 10:41 |
| rogpeppe | dimitern: (which, FWIW, would be wrong to use if you continue in the same direction - why should we have Life and ServiceLife not UnitLife and ServiceLife?) | 10:41 |
| rogpeppe | jam: yeah, LifeGetter allows arbitrary restrictions on what you can look at | 10:42 |
| dimitern | rogpeppe: so the auth func for LifeGetter should check AuthOwner for units and 1) get auth'ed entity, 2) compare it's service tag with the given tag - for services | 10:43 |
| dimitern | rogpeppe: and basically the same for AgentEntityWatcher as well | 10:44 |
| rogpeppe | dimitern: well, it could be simpler than that | 10:44 |
| rogpeppe | dimitern: it sounds reasonable. i'll wait to see the code | 10:45 |
| rogpeppe | dimitern: it basically comes down to: return tag == unit.Tag() || tag == names.ServiceTag(unit.ServiceName) | 10:46 |
| jam | rogpeppe: what is '.tsv' stand for? tab-separated-value (like csv, just with a \t ?) | 10:48 |
| dimitern | rogpeppe: I though you suggested having a way to get the auth'ed entity from the authorizier | 10:48 |
| rogpeppe | jam: yeah | 10:48 |
| dimitern | rogpeppe: like GetAuthEntity() interface{} | 10:48 |
| rogpeppe | dimitern: yes - the above is assuming you've got unit from there | 10:48 |
| rogpeppe | jam: i thought it was better than .txt and it does seem to have precedent | 10:48 |
| davecheney | good evening gentlemen | 10:49 |
| davecheney | i have a request from the far east | 10:50 |
| davecheney | i need to build a version of juju that does not attempt to create security groups on openstack/hp cloud | 10:50 |
| davecheney | is anyone able to help me ? | 10:51 |
| rogpeppe | davecheney: do you need tests to pass too? | 10:51 |
| davecheney | rogpeppe: no | 10:52 |
| rogpeppe | davecheney: have you tried just commenting out the code that creates the security groups? | 10:52 |
| davecheney | rogpeppe: yes, that is what I wanted to do | 10:52 |
| davecheney | i was hoping for some advice | 10:53 |
| davecheney | maybe I should just turn off the firewaller | 10:53 |
| rogpeppe | davecheney: hmm, without security groups, how can you open any ports at all? | 10:54 |
| rogpeppe | davecheney: 'cos presumably by default all ports are closed | 10:54 |
| davecheney | rogpeppe: according to marcoceppi they don't actually firewall anything | 10:55 |
| davecheney | just prevent most people from being able to deploy more than 10 services in total on their hp cloud account | 10:55 |
| jam | rogpeppe: I know in ec2, the default is that all machines in the same security group can talk to eachother on any port. I'm not sure about hp/openstack in general. | 10:55 |
| rogpeppe | davecheney: ah, so it should be irrelevant | 10:55 |
| rogpeppe | jam: presumably these machines won't be in the same security group (because we can't create one) | 10:55 |
| davecheney | jam: yeah, security groups in ec2 work | 10:56 |
| davecheney | they don't in hp cloud | 10:56 |
| jam | rogpeppe: I don't know that dave is asking for 0, just not 1-per-machine. | 10:56 |
| davecheney | so the creation of the groups just presents an annoying limit | 10:56 |
| rogpeppe | davecheney: ah, so you can create one group for the whole environment? | 10:57 |
| davecheney | rogpeppe: preferably zero | 10:57 |
| davecheney | groups | 10:57 |
| davecheney | wallyworld_: poing | 10:58 |
| davecheney | ping | 10:58 |
| rogpeppe | davecheney: in that case, i'd just see what happens when you change environ.setUpGroups to return nil, nil | 10:58 |
| davecheney | rogpeppe: ok, will do | 10:58 |
| wallyworld_ | davecheney: wat | 10:58 |
| fwereade | davecheney, otherwise firewall-mode global will create just one, if that helps? | 10:59 |
| marcoceppi | wallyworld_: we're going to be demoing on az1 and az2 "tomorrow", however last I checked az2 and az3 don't have simple stream data | 10:59 |
| rogpeppe | fwereade, davecheney: yes, that was going to be my other suggestion | 10:59 |
| wallyworld_ | marcoceppi: maybe not, i haven't checked. i did some initial data for az1 using the juju tool. if we need it for the other regions it will need to be hand crafted. when is "tomorrow"? | 11:00 |
| davecheney | fwereade: that might be better | 11:01 |
| jam | marcoceppi: there won't be simplestreams data in cloud-images, since hp isn't (yet) a CPC | 11:01 |
| davecheney | i'll try that | 11:01 |
| marcoceppi | wallyworld_: 12 hours from now | 11:01 |
| jam | wallyworld_: can we generate stuff and put it with the tools we copied over there ? | 11:01 |
| wallyworld_ | marcoceppi: ok, i'll see if i can whip something up tonight. i may not be around tomorrow as it's a holiday here. how long will you e around for now? | 11:02 |
| marcoceppi | jam: az1 data exits already, it'd be nice if az2 and 3 were also in there | 11:02 |
| marcoceppi | wallyworld_: I'll be around for 2-3 hours | 11:02 |
| wallyworld_ | jam: what he said - the existing nmetadata nwds to be added to | 11:02 |
| wallyworld_ | marcoceppi: ok, i'll see what i can do. maybe you could test once i do it | 11:03 |
| marcoceppi | wallyworld_: I'd be happy to test! | 11:03 |
| wallyworld_ | ok, leave it with me | 11:03 |
| wallyworld_ | marcoceppi: what image ids do we want? | 11:03 |
| wallyworld_ | there's a bug i think with those listed | 11:04 |
| marcoceppi | wallyworld_: thanks for taking a look! If not I can dig through the metadata plugin if you run out of time and put it in a seperate bucket | 11:04 |
| wallyworld_ | i'll see if i can find it | 11:04 |
| marcoceppi | wallyworld_: I'll double check in the console | 11:04 |
| marcoceppi | they may have changed | 11:04 |
| wallyworld_ | ok, if you tell me the images ids for az2 and az3 that would be great | 11:04 |
| wallyworld_ | marcoceppi: what series also | 11:04 |
| wallyworld_ | precise? | 11:04 |
| jam | wallyworld_: I see endpoint data but no content: https://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:hpcloud.sjson | 11:05 |
| wallyworld_ | jam: the data isn't there yet. it's in the hp cloud public bucket | 11:05 |
| jam | ah, ok. | 11:05 |
| * wallyworld_ wishes it was there | 11:06 | |
| davecheney | sorry, marcoceppi has lagged out | 11:06 |
| davecheney | he'll be back in a sec | 11:06 |
| davecheney | marcoceppi: firewall-mode: global | 11:09 |
| davecheney | fwereade: firewall-mode: global might be the trick for us | 11:09 |
| fwereade | davecheney, cool | 11:10 |
| fwereade | davecheney, glad it's good for something, I was worried about it for a while ;p | 11:10 |
| davecheney | fwereade: that means we're down to 2 sec groups per student | 11:10 |
| davecheney | that'll do | 11:10 |
| davecheney | we can squeak by | 11:10 |
| davecheney | thanks | 11:11 |
| marcoceppi | wallyworld_: yes, precise | 11:12 |
| wallyworld_ | ok | 11:12 |
| marcoceppi | wallyworld_: would it be possible to put the data in the same bucket as the one davecheney sends out during ANN for juju-core testing on hpcloud? | 11:12 |
| wallyworld_ | marcoceppi: yeah,that's what i'm doing | 11:13 |
| marcoceppi | wallyworld_: <3 awesome, thanks! | 11:13 |
| wallyworld_ | updating existing metadata | 11:13 |
| wallyworld_ | just need the images ids :-) | 11:13 |
| davecheney | wallyworld_: thanks man | 11:13 |
| wallyworld_ | anytime | 11:14 |
| davecheney | so far we've been able to avoid spinning custom tools | 11:14 |
| davecheney | there is one more problem which I'm not sure I can fix without changing the tools | 11:14 |
| wallyworld_ | yes? | 11:14 |
| davecheney | byobu doesn't interact well with tera term | 11:15 |
| marcoceppi | wallyworld_: AZ2: 68481 AZ3: 49850 | 11:15 |
| wallyworld_ | ta | 11:15 |
| davecheney | so I need to put `apt-get remove byobu` in the cloud-init so I can remove byobu and fall back to tmux | 11:15 |
| jam | wallyworld_: don't you need the uuids or HP being Diablo just has the short names | 11:16 |
| jam | ? | 11:16 |
| natefinch | morning all | 11:16 |
| wallyworld_ | jam: we support both uuids and ints transparently | 11:17 |
| natefinch | (and afternoon and evening as the case may be) | 11:17 |
| jam | hi natefinch | 11:17 |
| marcoceppi | wallyworld_: I created simplestream data a while a go for az3, if it helps | 11:18 |
| davecheney | natefinch: おはようございます | 11:19 |
| wallyworld_ | marcoceppi: i've done the new data, just using the validation tool to smoke test it. but i have no perms to re-upload it turns out | 11:19 |
| marcoceppi | wallyworld_: ack | 11:20 |
| davecheney | wallyworld_: sad trombone | 11:20 |
| wallyworld_ | marcoceppi: do you have permission to write to the public bucket? | 11:20 |
| natefinch | davecheney: ha. Sorta surprised google knew what to do with that. | 11:20 |
| marcoceppi | wallyworld_: no that I know of | 11:20 |
| wallyworld_ | marcoceppi: is arosales around? he can | 11:21 |
| davecheney | wallyworld_: arosales has been up for about a day | 11:21 |
| davecheney | he's been sorting out all our shit today | 11:21 |
| marcoceppi | wallyworld_: he may be around, but I'm not sure | 11:21 |
| davecheney | i think he's turned in | 11:21 |
| wallyworld_ | ok | 11:22 |
| marcoceppi | slacker ;) | 11:22 |
| noodles775 | rogpeppe: RE the HP provider returning ErrNoInstances, I just went to make the change to shortAttempt that you mentioned, but afaics from the bug, it's not related? That said, I *think* I found another potential cause... details in the description: https://codereview.appspot.com/12795045 | 11:22 |
| natefinch | only one day? | 11:22 |
| wallyworld_ | so what you can do is create a new container, make it globally readable, and put tools and new metadata in it | 11:22 |
| marcoceppi | wallyworld_: I might be able to actually, let me check | 11:22 |
| wallyworld_ | and set the public-bucket-url accordingly | 11:22 |
| rogpeppe | noodles775: looking | 11:24 |
| wallyworld_ | marcoceppi: davecheney: i have the new metadata if only we could write it | 11:25 |
| wallyworld_ | you guys need to give me more advance notice | 11:25 |
| davecheney | wallyworld_: i'll thank you personally for that helpful comment next week | 11:26 |
| wallyworld_ | davecheney: just saying | 11:26 |
| jam | wallyworld_: I have perms to the hp public bucket, but I thought you did, too. | 11:26 |
| davecheney | yeah, sorry, we're really hulk smashing this whole training | 11:26 |
| wallyworld_ | davecheney: just being a prick, sorry | 11:27 |
| davecheney | s'ok | 11:27 |
| davecheney | if that was the worst thing that had happende this week, i'd be upset | 11:27 |
| davecheney | but it isn't | 11:27 |
| davecheney | not by a long shot | 11:27 |
| wallyworld_ | jam: i logged in and can only see us-west | 11:27 |
| wallyworld_ | and cannot see the public bucket | 11:28 |
| marcoceppi | wallyworld_: I have a bukkit | 11:28 |
| wallyworld_ | marcoceppi: we may be able to write the files | 11:28 |
| rogpeppe | noodles775: good catch! | 11:28 |
| marcoceppi | \o/ | 11:28 |
| jam | wallyworld_: there is only 1 storage | 11:28 |
| jam | there are 3 computes | 11:28 |
| jam | they all use the same storage | 11:28 |
| rogpeppe | noodles775: looks like a good fix. it would be nice to be able to test it though. | 11:28 |
| jam | az3.geo-1, vs just geo-1 | 11:28 |
| jam | IIRC | 11:28 |
| wallyworld_ | jam: i can only see 3 containers, none of which is the public bucket when i log in | 11:29 |
| jam | wallyworld_: I see roughly the same thing, but we have the tools somewhere in that account :) | 11:29 |
| jam | wallyworld_: "control-bucket: juju-dist" | 11:30 |
| wallyworld_ | jam: ah, maybe i am a dickhead, there is a drop down with projects which i didnt see | 11:30 |
| wallyworld_ | let me try selecting the right project | 11:30 |
| jam | wallyworld_: I didn't see it either | 11:30 |
| jam | wallyworld_: https://console.hpcloud.com/object_store/region-a_geo-1/containers/juju-dist | 11:30 |
| wallyworld_ | yep, uploading now | 11:31 |
| wallyworld_ | marcoceppi: ready for testing | 11:31 |
| wallyworld_ | davecheney: ^^^ | 11:31 |
| jam | dimitern, rogpeppe, standup? https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 | 11:33 |
| davecheney | wallyworld_: ok, will test | 11:33 |
| davecheney | wallyworld_: thank you | 11:33 |
| jam | axw: ^^ | 11:33 |
| wallyworld_ | davecheney: np at all. if it doesn't work, i'll fix, let me know | 11:33 |
| davecheney | wallyworld_: http://paste.ubuntu.com/5980804/ | 11:35 |
| davecheney | ^ it's copying tools, is this expected ? | 11:35 |
| jam | davecheney: it wasn't expected for me | 11:35 |
| jam | do you have public-bucket-url set for HP? | 11:35 |
| davecheney | jam: sorr, i might have screwed up | 11:36 |
| wallyworld_ | yes, looks like public bucket is not set right if it can't see tools | 11:36 |
| davecheney | public-bucket-url: https://console.hpcloud.com/object_store/region-a_geo-1/containers/juju-dist | 11:36 |
| wallyworld_ | davecheney: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910 | 11:36 |
| davecheney | ok, that was what I had before | 11:37 |
| davecheney | my bad | 11:37 |
| wallyworld_ | davecheney: soon, public bucket will not be necessary at all \o/ | 11:37 |
| davecheney | 2013-08-13 11:37:34 INFO juju provider.go:734 environs/openstack: started instance "1670895" | 11:37 |
| davecheney | 2013-08-13 11:37:35 INFO juju supercommand.go:276 command finished | 11:37 |
| davecheney | got an instance in az3 | 11:37 |
| davecheney | rocking | 11:37 |
| wallyworld_ | yay \o/ | 11:37 |
| marcoceppi | ditto over here for az2 | 11:38 |
| * wallyworld_ is happy he wrote the image validation tool to check the metadata prior to copying to the bucket | 11:38 | |
| marcoceppi | just waiting for juju status to come back | 11:38 |
| davecheney | thanks so much for your help | 11:39 |
| wallyworld_ | my pleasre. good luck with the demo :-) | 11:39 |
| marcoceppi | wallyworld_: def, thank you sir! | 11:40 |
| wallyworld_ | anytime | 11:40 |
| noodles775 | rogpeppe: Thanks! And yeah - that was my next question. Any relevant examples you could point me at for tests? The ones in the respective provider_test.go are just for one particular function. Otherwise I'll hunt around. | 11:42 |
| rogpeppe | noodles775: in a call. be with you in a bit. | 11:42 |
| mgz | davecheney: I'm going to poke the release tarball script to use the revs from our new dependencies.tsv file | 11:47 |
| davecheney | mgz: sounds good to me | 11:53 |
| rvba | Anyone up for a one-liner? https://codereview.appspot.com/12852043 | 11:53 |
| davecheney | rvba: worst pickup line, ever | 11:54 |
| jam | wallyworld_: did you see: https://bugs.launchpad.net/juju-core/+bug/1211147 | 11:54 |
| _mup_ | Bug #1211147: Deploying service to bootstrap node causes debug-log to spew messages <juju-core:Triaged> <https://launchpad.net/bugs/1211147> | 11:54 |
| jam | You might want to give it a poke, since you have the most rsyslogd knowledge on the team. | 11:54 |
| davecheney | jam: yeah, jonathon totally blew up his environment with that one | 11:55 |
| wallyworld_ | jam: didn't see it, will look | 11:55 |
| marcoceppi | fwereade: I've got a question about optional relations in juju, if you set a relation to be optional: False, what happens? | 11:55 |
| fwereade | marcoceppi, nothing at all | 11:55 |
| davecheney | fwereade: is it purely decorative ? | 11:56 |
| fwereade | davecheney, essentially yes | 11:56 |
| marcoceppi | fwereade: will it ever do anything? | 11:56 |
| davecheney | fwereade: for ceremonial occasions ? | 11:56 |
| fwereade | marcoceppi, it is not currently a high priority | 11:56 |
| marcoceppi | I must admit, it's really pretty :) | 11:56 |
| wallyworld_ | jam: do we even support putting a service on the bootstrap node? | 11:57 |
| marcoceppi | fwereade: what's the idea of what it would do in the future when you guys are done with priority things and bored and want to implement it? | 11:57 |
| davecheney | wallyworld_: sure, didn't you write that ? | 11:58 |
| davecheney | or are you asking, as an optoin we'd be proud to tell customers about ? | 11:58 |
| wallyworld_ | i didn't write it | 11:58 |
| wallyworld_ | i really didn't think we supported it | 11:58 |
| fwereade | davecheney, marcoceppi: there was talk, a long time ago, that we might automatically create non-optional relations between matching services, but that always seemed kinda crazy to me | 12:00 |
| fwereade | davecheney, marcoceppi: there *may* be some mileage in the idea that we just flag non-optional relations that are not satisfied | 12:00 |
| fwereade | davecheney, marcoceppi: but doing anything automatic in response seems like a really bad idea to me, because even if we think of something useful to do with it I can't see how it wouldn't be a terrifying behaviour change | 12:01 |
| marcoceppi | fwereade: My thought was, if a relation is not optional, it wouldn't "deploy" the charm until juju was aware of the relation via add-relation, must like the subordinate mechanism | 12:01 |
| davecheney | fwereade: some background, our students are interesting optional: false relations because they are thinking it will help them know when a service is properly deployed | 12:01 |
| davecheney | ie, all it's non optoinal relationships are fulfilled | 12:02 |
| fwereade | wallyworld_, rogpeppe, I can hear you | 12:04 |
| fwereade | wallyworld_, rogpeppe, but can't seem to say anything you can hear... brb | 12:04 |
| jam | fwereade: one more thing for you to glance at quickly: https://code.launchpad.net/~rogpeppe/juju-core/359-no-lax/+merge/178357 (As you were the one that implemented the StartSync vs Sync schism, you should at least be aware that it has all been migrated to Sync) | 12:16 |
| dimitern | rogpeppe: updated https://codereview.appspot.com/12849043 | 12:19 |
| dimitern | jam: take a look as well? ^^ | 12:19 |
| rogpeppe | jam: i'd like your thoughts on that too | 12:20 |
| rogpeppe | jam: 359-no-lax that is | 12:20 |
| wallyworld_ | fwereade: we lost you again? | 12:20 |
| fwereade | wallyworld_, I can hear you, but I'll rejoin | 12:21 |
| fwereade | wallyworld_, yeah, it doesn't want to let me rejoin :/ | 12:21 |
| axw | jam: sorry, was having dinner earlier | 12:28 |
| jam | axw: np. I don't know that it will work in your Timezone, but we do a whole group get-together at UTC 11:30 | 12:29 |
| jam | I think Tim was thinking of doing another one earlier in the day | 12:29 |
| jam | for those in the high UTC offsets. | 12:29 |
| jam | axw: I added you to the calendar entry, but it is optional for you, since it is roughly dinner/family/anything-that-isn't-work time for you. | 12:30 |
| axw | jam: thanks for that. I hit "maybe" because of that, but I'll try to make it sometimes. If there's something important, just let me know and I'll be there | 12:31 |
| jam | axw: it is just our daily "catch up with eachother on what we're working on". You should have a weekly 1:1 with either Mark or Tim already for the "important" things. | 12:32 |
| dimitern | rogpeppe: does it look better now? | 12:39 |
| rogpeppe | dimitern: sorry, still in a call | 12:40 |
| rogpeppe | fwereade: you've frozen again... | 12:41 |
| fwereade | wallyworld_, rogpeppe, did I get cut off again? | 12:42 |
| rogpeppe | fwereade: yes | 12:42 |
| wallyworld_ | yep | 12:42 |
| dimitern | rogpeppe: np | 12:43 |
| dimitern | natefinch, mgz: second review on https://codereview.appspot.com/12849043 please? | 12:43 |
| mramm | hey all | 12:43 |
| mgz | dimitern: sure | 12:43 |
| dimitern | mgz: cheers | 12:44 |
| dimitern | mgz: just note I forgot to update the description - ServiceLife, ServiceCharmURL and WatchService are gone, replaced (as suggested by rog) with Life, Watch amd CharmURL handling both units and services | 12:45 |
| mramm | is it an lxc prereq issue that causes this error: | 12:46 |
| mramm | 08:41 danwest: $ juju -v bootstrap | 12:46 |
| mramm | 08:41 danwest: 2013-08-13 12:40:06 INFO juju.environs.local environprovider.go:32 opening environment "local" | 12:46 |
| mramm | 08:41 danwest: 2013-08-13 12:40:06 ERROR juju.environs.local net.go:18 cannot find network interface "lxcbr0": net: no such interface | 12:46 |
| mramm | 08:41 danwest: 2013-08-13 12:40:06 ERROR juju.environs.local environprovider.go:44 failure setting config: net: no such interface | 12:46 |
| mramm | 08:41 danwest: 2013-08-13 12:40:06 ERROR juju supercommand.go:235 command failed: net: no such interface | 12:46 |
| mramm | 08:41 danwest: error: net: no such interface | 12:46 |
| dimitern | mramm: you need sudo juju bootstrap with the local provider | 12:47 |
| mramm | ahh | 12:47 |
| dimitern | mramm: but apart from that it might be something else | 12:47 |
| dimitern | (prereq issue) | 12:47 |
| mramm | ok | 12:48 |
| mramm | I will tell him to try that | 12:48 |
| mramm | also we should give a better error message there too | 12:48 |
| mramm | sudo did not fix it | 12:49 |
| dimitern | so it's a different issue | 12:49 |
| dimitern | we recently updated the README I think wrt the local provider | 12:50 |
| dimitern | nope, it's not in yet | 12:50 |
| mramm | also, installing lxc was not the fix | 12:52 |
| mramm | I am having him file a bug | 12:52 |
| dimitern | mramm: I found this thread http://comments.gmane.org/gmane.linux.kernel.containers.lxc.general/3819 - it says to check /var/log/upstart/lxc* for errors | 12:54 |
| danwest | dnsmasq: failed to create listening socket for 10.0.3.1: Address already in use | 12:55 |
| danwest | hmm, if true should handle that a bit more gracefully | 12:55 |
| danwest | looking into it now | 12:55 |
| mramm | agreed | 12:56 |
| dimitern | danwest: yup, that's what was mentioned in that thread as well | 12:56 |
| dimitern | mramm, danwest: it seems an lxc issue though, not a juju issue | 12:56 |
| mramm | juju should handle that if nessisary | 12:56 |
| mramm | I mean we should talk to serge and whatnot, but juju needs to just work or at the very least give good error messages | 12:57 |
| dimitern | mramm: agreed, that specific error means gonet wasn't able to open the interface lxcbr0 | 12:58 |
| danwest | same issue after killing dnsmasq | 12:58 |
| dimitern | danwest: take a look what's listening on 10.0.3.1 | 12:58 |
| danwest | tftp | 13:00 |
| danwest | nothing | 13:01 |
| dimitern | maybe it starts dnsmasq twice or something? anything else useful in the log? | 13:01 |
| danwest | nothing in the log, actually the entry must have been old as I moved the log aside and re-ran - no new lxc log | 13:03 |
| danwest | entry was not timestamped | 13:03 |
| dimitern | danwest: sorry, perhaps hallyn_ or someone else with more in-depth knowledge of lxc can help | 13:04 |
| danwest | dimitern: thx | 13:06 |
| hallyn_ | danwest: i need to deal with some movers for the next hour. addres already in use is weird. can you reproduce at will? can you email or pastebin a reproducer? | 13:08 |
| danwest | hallyn_: will try, thx | 13:09 |
| hallyn_ | (or just a launchpad bug against lxc :) | 13:10 |
| hallyn_ | danwest: oh wait - are you starting containers nested, inside lxc? | 13:10 |
| danwest | hallyn_: nope | 13:11 |
| hallyn_ | danwest: if so then you may be running an older lxc - it shoudl fall back to 10.0.4.x if 10.0.3.x is taken by the | 13:11 |
| hallyn_ | ok | 13:11 |
| hallyn_ | thx, ttyl :) | 13:11 |
| dimitern | jam: so, suggestions about what error should we return when len(entities) == 0 ? | 13:12 |
| dimitern | jam: thanks for the review btw | 13:12 |
| mgz | hm, I find that latest branch a little hard to follow dimitern | 13:16 |
| dimitern | mgz: oh? what's not clear? | 13:16 |
| mgz | various changes made so CharmURl also support services? then I'm not clear on the new getCanAccessUnitOrService func | 13:19 |
| dimitern | mgz: yes, as rogpeppe suggested | 13:19 |
| dimitern | mgz: the new authFunc checks if you're allowed to access the given tag, which is either a unit or service | 13:20 |
| dimitern | mgz: in the latter case, you can access it only if it matches your authentication entity (unit)'s service | 13:20 |
| mgz | okay, and it works, because a unit tag will never match a service tag, | 13:21 |
| dimitern | mgz: it's used in CharmURL to allow both unit and service tags as args | 13:21 |
| mgz | so the extra code will always get passed over in the unit case... | 13:21 |
| dimitern | no | 13:21 |
| dimitern | the code is the same for a unit or a service - both support CharmURL (string, bool) | 13:22 |
| mgz | right, but passing a unit to CharmURL now uses a different auth check | 13:22 |
| dimitern | yes | 13:22 |
| mgz | but... if a unit is passed, it will still end up calling AuthOwner(tag) the same as before | 13:22 |
| dimitern | no actually, it's still the same | 13:22 |
| dimitern | it's just extended | 13:22 |
| dimitern | yeah | 13:23 |
| dimitern | in case it's not an auth'ed service tag | 13:23 |
| dimitern | AuthOwner will never work for anything else than a unit tag | 13:23 |
| mgz | those two funcs don't actually need closures, right? | 13:23 |
| dimitern | and services cannot log in anyway | 13:23 |
| mgz | could you put them at top level with doc comments before assigning into UniterAPI? | 13:24 |
| dimitern | we need to pass them to LifeGetter and AgentEntityWatcher as well | 13:24 |
| dimitern | why? they need the authorizer that was passed to NewUniterAPI | 13:25 |
| dimitern | and they're used only there | 13:25 |
| dimitern | using closures like this is nice, because we're currying the authorizer as an implict arg | 13:26 |
| mgz | ah, they do need closures, hadn't notices authorizer was a param not a package | 13:26 |
| dimitern | yep | 13:26 |
| mgz | well, lgtmed. | 13:26 |
| dimitern | cheers! | 13:26 |
| dimitern | rogpeppe: I'll wait for you to take a look before landing | 13:27 |
| rogpeppe | dimitern: i'm still looking at it | 13:27 |
| rogpeppe | dimitern: reviewed | 13:41 |
| dimitern | rogpeppe: thanks | 13:42 |
| dimitern | rogpeppe: i don't want to return Entity there - I want the real thing | 13:42 |
| dimitern | rogpeppe: in GetAuthEntity | 13:42 |
| rogpeppe | dimitern: what? | 13:42 |
| rogpeppe | dimitern: state.Entity is more real than interface{} | 13:43 |
| dimitern | rogpeppe: but does it have CharmURL and any other method I might need? | 13:43 |
| rogpeppe | dimitern: no, but anything is better than bare interface{} | 13:43 |
| rogpeppe | dimitern: at least state.Entity suggests the type that it might be returning | 13:44 |
| dimitern | rogpeppe: so what, for each method we need we have to change state.Entity to add that method? | 13:44 |
| rogpeppe | dimitern: the set of types | 13:44 |
| rogpeppe | dimitern: ??? | 13:44 |
| rogpeppe | dimitern: interface{} has no methods at all. | 13:44 |
| dimitern | rogpeppe: no, but I can do entity.(*state.Unit).CharmURL() on it | 13:45 |
| rogpeppe | dimitern: just as you can if it's state.Entity | 13:45 |
| rogpeppe | dimitern: there's no difference in that respect | 13:45 |
| dimitern | rogpeppe: so you can cast any type, no just an interface{} ? | 13:45 |
| rogpeppe | dimitern: um, yes? | 13:45 |
| dimitern | rogpeppe: c-style? | 13:45 |
| rogpeppe | dimitern: any interface type | 13:45 |
| rogpeppe | dimitern: and state.Entity is an interface | 13:46 |
| dimitern | rogpeppe: hmm | 13:46 |
| dimitern | rogpeppe: ok then, I'll try it | 13:46 |
| rogpeppe | dimitern: thanks | 13:46 |
| * rogpeppe gets some lunch | 13:47 | |
| dimitern | anyone: next one in line https://codereview.appspot.com/12850044 | 13:55 |
| jam | natefinch: did you see: https://code.launchpad.net/~michael.nelson/juju-core/1208504-post-bootstrap-hp-no-instances-found-try2/+merge/179899 I think noodles775 has touched the same code as you, but I might be thinking of the wrong patch (I've gone through a lot of patches today :) | 13:58 |
| jam | dimitern: len(entities) == 0 can just be kept the same way. If we do decide to change it, then "ErrNoArgs" or something along those lines. But it would be a policy change across the board so it should be thought about and discussed I think. | 13:59 |
| * jam I'm off for now | 13:59 | |
| noodles775 | natefinch, jam: happy to reject mine if it's already fixed :) | 14:00 |
| dimitern | jam: I decided to remove it | 14:03 |
| dimitern | jam: when we introduce backward-incompatible changes to params we'll have to take that into account, like for SetStatus | 14:03 |
| jam | dimitern: well we need it in place *before* we make an incompatible change, otherwise the "old servers don't error on new requests" is still valid. | 14:05 |
| jam | anyway, it is a separate change from what you're doing. | 14:05 |
| dimitern | jam: yep | 14:06 |
| natefinch | jam, noodles775: looking now | 14:08 |
| natefinch | jam, noodles775: looks very different from my changes. Mine is more focused on when you really haven't bootstrapped yet, rather than bootstrapping not being finished | 14:14 |
| natefinch | jam, noodles775: I think they're complimentary changes, and shouldn't affect one another | 14:14 |
| noodles775 | natefinch: Cool - thanks for checking. | 14:15 |
| jam | ah, both noodles775 patches. https://codereview.appspot.com/12755043/ vs https://codereview.appspot.com/12795045/ | 14:16 |
| jam | noodles775: is https://codereview.appspot.com/12795045/ supposed to supersede the other? | 14:17 |
| noodles775 | jam: yeah it is. I'd not realised you'd commented on the former - it should be closed. | 14:18 |
| * noodles775 closes. | 14:18 | |
| jam | noodles775: I tend to drive reviews from my email folder, so that doesn't always help :) | 14:18 |
| dimitern | mgz, jam, rogpeppe: when you have some time PTAL https://codereview.appspot.com/12850044 | 14:18 |
| fwereade | rogpeppe, so, https://codereview.appspot.com/12352044/ | 14:22 |
| fwereade | rogpeppe, your analysis is I think correct | 14:22 |
| * rogpeppe breathes a sigh of relief | 14:22 | |
| fwereade | rogpeppe, but you removed a great big pile of test coverage with the "fix" | 14:22 |
| dimitern | rogpeppe: also updated https://codereview.appspot.com/12849043/ | 14:22 |
| fwereade | rogpeppe, and AFAICT it could have been resolved with a LaxStringsWatcher at the end of the unit and machine tests | 14:23 |
| rogpeppe | fwereade: really? | 14:23 |
| fwereade | er LaxNotifyWatcher | 14:23 |
| rogpeppe | fwereade: what's no longer tested? | 14:23 |
| fwereade | rogpeppe, well, unless you removed the coalescence behaviour and verified that the tests failed | 14:23 |
| rogpeppe | fwereade: i didn't understand why StartSync tests coalescence that Sync doesn't | 14:23 |
| fwereade | rogpeppe, which they wouldn't have done, because the Sync version essentially forces coalescence irrespective of watcher implementation | 14:24 |
| fwereade | rogpeppe, because the Sync tests force all events to have been read before we read from the watcher | 14:24 |
| fwereade | rogpeppe, the StartSync ones were explicitly there to test what happened when we read from the out channel before the in channel was exhausted | 14:25 |
| rogpeppe | fwereade: i still don't quite see it | 14:26 |
| rogpeppe | fwereade: the difference between StartSync and Sync is just one or two scheduling decisions. I don't see how that can be the basis of a reliable test. | 14:27 |
| fwereade | rogpeppe, the point is that Sync will always pass, while StartSync will sometimes fail if the behaviour's wrong | 14:27 |
| rogpeppe | fwereade: perhaps you could describe to me a possible failure mode when using StartSync | 14:28 |
| fwereade | rogpeppe, more reliability is good, I would be happier if the tests could reliably pass/fail in all circumstances | 14:28 |
| rogpeppe | fwereade: so I can understand what we're trying to guard against | 14:28 |
| sidnei | fwereade: https://codereview.appspot.com/12859043 and https://bugs.launchpad.net/juju-core/+bug/1201503 's comments for some investigation | 14:30 |
| _mup_ | Bug #1201503: Add os disk constraint <constraints> <juju-core:Triaged by sidnei> <https://launchpad.net/bugs/1201503> | 14:30 |
| * arosales reading backscroll, looks like wallyworld_ jam figured out the public bucket issue | 14:31 | |
| fwereade | sidnei, cheers | 14:32 |
| * fwereade continues to try to marshal a clear argument for rogpeppe | 14:33 | |
| * rogpeppe continues to wear a slightly puzzled expression | 14:34 | |
| * fwereade might have come up with an illustrative question | 14:37 | |
| rogpeppe | fwereade: are you talking specifically about testing the behaviour of the collect function? | 14:38 |
| fwereade | rogpeppe, how is it possible for us to test event coalescence when Sync is the only tool in play? | 14:38 |
| fwereade | rogpeppe, yeah | 14:38 |
| fwereade | rogpeppe, whenever we Sync we force the watcher to finish handling all events before we even try to read from Shanges | 14:39 |
| fwereade | rogpeppe, er Changes | 14:40 |
| rogpeppe | fwereade: how's that? | 14:40 |
| rogpeppe | oh, i see | 14:40 |
| fwereade | rogpeppe, so you are perfectly correct about what was going on | 14:41 |
| fwereade | rogpeppe, it's somewhat interesting that a case could be made that the tests were failing due to a hard-to-detect bug in the watcher implementation | 14:42 |
| fwereade | rogpeppe, but changing that stopped us from being able to detect similar bugs that would I think unarguably be bugs | 14:42 |
| rogpeppe | fwereade: it depends what semantics you expect from StartSync really | 14:42 |
| fwereade | rogpeppe, as opposed to this behaviour which is, er, arguable | 14:43 |
| dimitern | rogpeppe: should I land https://codereview.appspot.com/12849043/ now? I think I did all you asked | 14:43 |
| fwereade | rogpeppe, I just expect it to return as soon as possible, and for that to leave a moderate chance of detecting collect bugs | 14:44 |
| dimitern | mgz: hey | 14:44 |
| rogpeppe | fwereade: i *think* the tests could still break when coalescence is disabled and using Sync | 14:44 |
| rogpeppe | dimitern: looking | 14:44 |
| rogpeppe | fwereade: in fact, i might try that out | 14:45 |
| dimitern | mgz: https://codereview.appspot.com/12850044 quick review? | 14:45 |
| fwereade | rogpeppe, I think that NotifyWatcher and StringsWatcher are safe from that, and I couldn't repro it just now, but I didn't try very hard | 14:45 |
| fwereade | rogpeppe, any more complex watcher where there's another layer in play is vulnerable | 14:45 |
| fwereade | rogpeppe, but NW and SW only have one select loop, and as soon as the last event's been delivered the watcher finishes processing it before going round again and potentially sending on Changes | 14:46 |
| rogpeppe | fwereade: i think a better way of testing coalescence is to make the test start a goroutine to transfer all events into a buffered channel, then call Sync | 14:47 |
| rogpeppe | fwereade: as a specific coalescence test | 14:49 |
| fwereade | rogpeppe, yeah, that sounds nice | 14:49 |
| fwereade | rogpeppe, but that sort of test does get rather tricky to follow... iirc you argued against that sort of approach when I first proposed it | 14:50 |
| rogpeppe | fwereade: istm that's a better approach than spraying StartSync about the place as if it's testing something specific | 14:50 |
| fwereade | rogpeppe, well, hmm | 14:51 |
| rogpeppe | fwereade: i'd have only one test like that for each watcher | 14:51 |
| fwereade | rogpeppe, I think that Sync is very hard to justify | 14:51 |
| rogpeppe | fwereade: i think that StartSync is even harder to justify :-) | 14:51 |
| fwereade | rogpeppe, expand please, Sync STM to be much further divorced from anything resembling a real situation | 14:52 |
| fwereade | rogpeppe, you know what | 14:52 |
| rogpeppe | fwereade: StartSync gives you no guarantees at all, which makes it hard to write reliable tests | 14:52 |
| fwereade | rogpeppe, fuck both sync and startsync, we should just patch out the watcher period | 14:52 |
| fwereade | rogpeppe, but Sync is completely fake and makes it very easy to write completely useless tests | 14:53 |
| dimitern | fwereade: actually that sgtm | 14:53 |
| mgz | dimitern: looking | 14:53 |
| dimitern | fwereade: we call Sync to make sure the events have arrived, if we patch the watcher period, we can guarantee that | 14:54 |
| fwereade | dimitern, hmm, though, I think we still need *some* sort of machinery somewhere, or to make *very very* timing-dependent tests, which ain't great | 14:56 |
| rogpeppe | dimitern: how can we guarantee that? | 14:56 |
| rogpeppe | dimitern: timing isn't guaranteed, as fwereade says above | 14:56 |
| rogpeppe | dimitern: i still don't quite understand why you need getUnitOrService | 14:57 |
| dimitern | rogpeppe: for cases like Life, Watch and CharmURL | 14:57 |
| rogpeppe | dimitern: why not just call State.Entity directly in those cases? | 14:57 |
| dimitern | rogpeppe: there's no state.Entity() | 14:58 |
| dimitern | rogpeppe: there's FindEntity and what's wrong with my approach? | 14:58 |
| rogpeppe | dimitern: oh yeah, FindEntity, sorry! | 14:58 |
| rogpeppe | dimitern: what does getUnitOrService give you that State.FindEntity doesn't? | 14:58 |
| dimitern | rogpeppe: better validation of expected tag kinds? | 14:59 |
| rogpeppe | dimitern: that's already validated by canAccess, no? | 14:59 |
| dimitern | rogpeppe: no | 15:00 |
| dimitern | rogpeppe: it only checks if you can access it | 15:00 |
| dimitern | rogpeppe: it's not validating tag kinds | 15:00 |
| dimitern | rogpeppe: a bit of extra sanity checking at the expense of 3-4 lines seems like a good idea | 15:01 |
| dimitern | rogpeppe: and it's only done once in getUnitorService | 15:01 |
| rogpeppe | dimitern: how could canAccessUnitOrService return true for a tag that wasn't a service or a unit? | 15:01 |
| dimitern | rogpeppe: when state is flawed somehow? | 15:01 |
| rogpeppe | dimitern: i think it's worth having clear security checking boundaries, rather than just piling extra checks on like they might help | 15:02 |
| dimitern | rogpeppe: you have a unit that has an invalid service attached to it? | 15:02 |
| rogpeppe | dimitern: there are hundreds of ways we could go wrong if our code is flawed | 15:02 |
| rogpeppe | dimitern: you're *already* assuming that canAccessUnitOrService is operating as expected | 15:03 |
| dimitern | rogpeppe: I didn't say our code is flawed | 15:03 |
| dimitern | rogpeppe: I said the state in mongo might be invalid | 15:03 |
| rogpeppe | [16:01:58] <dimitern> rogpeppe: when state is flawed somehow? | 15:03 |
| dimitern | rogpeppe: ^^ | 15:04 |
| dimitern | (to many things called "state") | 15:04 |
| rogpeppe | dimitern: even if the state in mongo is invalid, your checks would still not fail | 15:04 |
| noodles775 | rogpeppe: for later/tomorrow/next week, I've also updated the interspersed flags based on our conv. yesterday: https://codereview.appspot.com/12603047 | 15:04 |
| rogpeppe | dimitern: there's no way we can return a *Unit from a service- tag | 15:05 |
| rogpeppe | noodles775: thanks | 15:05 |
| dimitern | rogpeppe: ok, I give up | 15:05 |
| rogpeppe | dimitern: i'm only trying to get us to write less, simpler, code | 15:05 |
| dimitern | rogpeppe: I'm getting rid of getServiceOrUnit and replacing it with FindEntity | 15:05 |
| rogpeppe | dimitern: cool, thanks | 15:05 |
| dimitern | rogpeppe: I want to land this already | 15:05 |
| dimitern | rogpeppe: but will keep the getUnit and getService helpers | 15:06 |
| rogpeppe | dimitern: yeah, i thought they were worth it for the static type conversion | 15:06 |
| rogpeppe | s/conversion/return | 15:07 |
| === tasdomas is now known as tasdomas_afk | ||
| dimitern | rogpeppe: reproposing with that change | 15:08 |
| dimitern | rogpeppe: done | 15:09 |
| === BradCrittenden is now known as bac | ||
| dimitern | rogpeppe: was that the only issue that needed fixing? | 15:13 |
| dimitern | mgz: thanks | 15:13 |
| rvba | rogpeppe: I think that review is for you :). Nothing urgent though, it's just a clean-up. https://codereview.appspot.com/12861043/ | 15:14 |
| rogpeppe | dimitern: reviewed. thanks for bearing with me! | 15:14 |
| fwereade | noodles775, just looking at https://codereview.appspot.com/12603047/patch/11001/12004 | 15:15 |
| fwereade | noodles775, what extra args were you expecting for debug-log | 15:15 |
| fwereade | ? | 15:15 |
| dimitern | rogpeppe: thanks | 15:16 |
| rogpeppe | rvba: LGTM | 15:16 |
| rogpeppe | fwereade: well, debug-log does say that it accepts ssh args | 15:18 |
| rogpeppe | fwereade: which seems weird to me, but there y'go | 15:18 |
| fwereade | rogpeppe, seems weird to me too | 15:18 |
| noodles775 | fwereade: I wasn't expecting any... but debug-log apparently doesn't embed CommandBase (at least, I got a compile error saying it wasn't implementing the iface due to the missing method). | 15:18 |
| rogpeppe | fwereade: do we know what people might use that feature for? | 15:19 |
| noodles775 | fwereade: so I needed to add the method - happy to update it to instead return CommandBase.AllowInterspersedFlags which defaults to true). | 15:19 |
| fwereade | rogpeppe, afraid not... wallyworld_ implemented it iirc | 15:19 |
| rogpeppe | fwereade: does the python version allow arbitrary ssh args there, d'ya know? | 15:20 |
| fwereade | rogpeppe, the only case I can think of is needing to pass args down to ssh to cause that to work, but that seems surprising... an indicator of a different bug maybe? | 15:20 |
| fwereade | rogpeppe, looks like it doesn't | 15:21 |
| fwereade | rogpeppe, OTOH it *does* accept a bunch of other args that we don;t | 15:22 |
| rogpeppe | fwereade: ha ha | 15:22 |
| fwereade | rogpeppe, including, it seems, "--replay" equivalent to your requested "--all" | 15:22 |
| fwereade | rogpeppe, although I think I still disapprove ;p | 15:22 |
| rogpeppe | fwereade: i will definitely use --all most of the time, despite the bandwidth | 15:23 |
| fwereade | noodles775, cool, I think if we just make it match CommandBase I'll be happy | 15:23 |
| rogpeppe | fwereade: it would be nice to have a "last x minutes" flag though | 15:23 |
| fwereade | rogpeppe, not to mention filtering | 15:23 |
| rogpeppe | fwereade: yeah, that too | 15:24 |
| fwereade | noodles775, reviewed, LGTM with that change | 15:24 |
| fwereade | noodles775, thanks | 15:24 |
| noodles775 | Thanks fwereade, updating now. | 15:25 |
| rogpeppe | noodles775: reviewed | 15:28 |
| rogpeppe | fwereade: cmd.ParseArgs can go, yay! | 15:29 |
| rogpeppe | noodles775: i'm very happy how that turned out | 15:29 |
| noodles775 | rogpeppe: yeah, much nicer - thanks for the suggestions. | 15:29 |
| noodles775 | rogpeppe: erm, you meant s/false/true when you said "I'd just return false here" didn't you? (as per fwereade, we just want the same behavior as CommandBase) | 15:32 |
| rogpeppe | noodles775: oh, possibly, yes, assuming we *don't* want to allow arbitrary ssh args to be passed through | 15:33 |
| noodles775 | Right. | 15:33 |
| noodles775 | rogpeppe: sorry, another question - when you say that ParseArgs can now be removed, are you meaning I should add SuperCommand.AllowInterspersedFlags() returning false, or is there another reason why it'll just work that I'm missing? | 15:43 |
| noodles775 | rogpeppe: nm - I see you said that later. | 15:46 |
| rogpeppe | noodles775: that's the main reason i'm particularly happy with this change | 15:47 |
| rogpeppe | noodles775: the non-interspersing parsing of supercommand was a hack, but now it just falls out naturally. | 15:48 |
| noodles775 | Great :-) | 15:48 |
| rogpeppe | noodles775: it also means that supercommands can now nest nicely if we want them to | 15:48 |
| natefinch | trying to land a branch, but bzr is saying it can't get the lock on the branch.... from natefinch@bazaar.canonical.com. That seems bad. | 16:00 |
| natefinch | Maybe I'm doing something wrong | 16:00 |
| natefinch | rogpeppe, dimitern, mgz: any thoughts on ^ | 16:05 |
| rogpeppe | natefinch: can you paste the message you're getting? | 16:06 |
| natefinch | nate@Asgard:~/code/src/launchpad.net/juju-core$ bzr push lp:~natefinch/juju-core/juju-core | 16:06 |
| natefinch | Unable to obtain lock held by natefinch@bazaar.launchpad.net on taotie (process #25639), acquired 9 minutes, 56 seconds ago. | 16:06 |
| natefinch | See "bzr help break-lock" for more. | 16:06 |
| natefinch | bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~natefinch/juju-core/juju-core/ | 16:06 |
| _mup_ | Bug #25639: gs-gpl - .getdeviceparams gets called with broken types <gs-gpl (Ubuntu):Invalid> <gs-gpl (Debian):Fix Released> <https://launchpad.net/bugs/25639> | 16:06 |
| rogpeppe | natefinch: why are you naming your branch "juju-core"? | 16:06 |
| natefinch | I was attempting to follow a document Frank gave me - https://docs.google.com/document/d/1G74QKbJqPLooEBVPOeB5qgJSQ5fb7KGpmUTTjIK0NnQ/edit | 16:07 |
| natefinch | rogpeppe: I may have done something wrong :) | 16:07 |
| rogpeppe | natefinch: ah, i think those instructions are misleading | 16:08 |
| rogpeppe | natefinch: we usually make a unique (to the user) name for each new branch | 16:09 |
| rogpeppe | natefinch: (personally, i use branch names of the form 999-description, so i can remember the order i created them in) | 16:09 |
| natefinch | I tried that... at least, I thought so. I had named it 002-bootstrap or something like that. Obviously not quite the right thing | 16:10 |
| rogpeppe | natefinch: ah, actually that is suggested in that document: "bzr push --remember lp:~themue/juju-core/001-my-useful-change" | 16:10 |
| rogpeppe | natefinch: when you write "bzr push lp:~natefinch/juju-core/juju-core" you're trying to push it to a branch named "juju-core" in your lp space | 16:10 |
| rogpeppe | natefinch: which seems to exist already | 16:10 |
| dimitern | natefinch: I saw that yesterday | 16:11 |
| dimitern | natefinch: note - it's better never to interrupt lbox (^C) once started | 16:11 |
| natefinch | dimitern: I may have done that once or twice :/ | 16:11 |
| dimitern | natefinch: just do bzr break-lock bzr+ssh://bazaar.launchpad.net/... (the branch it told you) | 16:11 |
| dimitern | natefinch: and then repropose, should work | 16:12 |
| rogpeppe | natefinch: i've also got a lock held | 16:12 |
| rogpeppe | Unable to obtain lock held by rogpeppe@bazaar.launchpad.net on taotie (process #30432), acquired 1205 hours, 16 minutes ago. | 16:12 |
| _mup_ | Bug #30432: skim is hung on with "sudo kate" <skim (Ubuntu):Invalid> <https://launchpad.net/bugs/30432> | 16:12 |
| rogpeppe | See "bzr help break-lock" for more. | 16:12 |
| dimitern | natefinch: and yes, it's better to pick some names for your branches | 16:12 |
| rogpeppe | natefinch: :-) | 16:12 |
| rogpeppe | natefinch: it's actually quite useful, because it's on lp:~rogpeppe/juju-core/trunk | 16:13 |
| natefinch | dimitern: I tried to... I think I just misread something somewhere | 16:13 |
| rogpeppe | natefinch: and the lock message warns me that i've forgotten to rename my branch again | 16:13 |
| rogpeppe | natefinch: are you using cobzr? | 16:14 |
| natefinch | rogpeppe: no, but only because I don't know what it is :) | 16:14 |
| rogpeppe | natefinch: http://labix.org/cobzr | 16:15 |
| rogpeppe | natefinch: some people hate it | 16:15 |
| rogpeppe | natefinch: i find it works pretty well for me | 16:15 |
| natefinch | rogpeppe: man that guy is prolific :) | 16:15 |
| rogpeppe | natefinch: ain't it so | 16:15 |
| rogpeppe | natefinch: i define bzr as cobzr (i use a shell function) | 16:16 |
| natefinch | rogpeppe: ahh, this was what mgz was using yesterday... I was wondering how he did that switching between branches | 16:16 |
| rogpeppe | natefinch: i think you can use a bzr feature too, but i don't know how to do that | 16:16 |
| rogpeppe | natefinch: i usually do: cobzr branch lp:juju-core/trunk | 16:17 |
| rogpeppe | natefinch: then: cobzr switch trunk | 16:17 |
| rogpeppe | natefinch: then: cobzr checkout -b 123-my-new-branch | 16:17 |
| rogpeppe | natefinch: then edit the branch, commit, and lbox propose | 16:17 |
| natefinch | rogpeppe: that looks pretty good | 16:17 |
| rogpeppe | natefinch: i can switch between branches with cobzr switch branch-name | 16:17 |
| rogpeppe | natefinch: and i can keep the same GOPATH for most development purposes | 16:18 |
| rogpeppe | natefinch: (i actually keep another one for testing against different go versions) | 16:18 |
| natefinch | rogpeppe: yeah, that was immediately my thought... having multiple branches in the same directory is a big help. I've been renaming ones I'm not actively working on, but that's kind of a headache | 16:19 |
| rogpeppe | natefinch: i've got 307 branches in my juju-core tree currently :-) | 16:19 |
| * rogpeppe should probably do some garbage collection some time | 16:20 | |
| natefinch | rogpeppe: disk space is cheap :) | 16:20 |
| rogpeppe | natefinch: yeah, it's only 54MB | 16:20 |
| mgz | natefinch: no, I was using native colo | 16:22 |
| mgz | it's got a few quirks, but is far less buggy | 16:23 |
| natefinch | mgz: I saw it was an upcoming feature.. what version of bzr are you on? | 16:24 |
| mgz | natefinch: the one in the current distro/ppa for older versions | 16:25 |
| natefinch | mgz: ahh yeah, it looks like my version (2.6) has it. Cool. | 16:26 |
| mgz | so, `apt-add-repository ppa:bzr/ppa` if you're on precise or something | 16:26 |
| mgz | right, 2.6 is what you need | 16:26 |
| === natefinch is now known as natefinch-lunch | ||
| natefinch-lunch | back in a bit... thanks for the help | 16:29 |
| === natefinch-lunch is now known as natefinch | ||
| natefinch | mgz, rogpeppe, dimitern: can one of you (or anyone else) help me detangle my bzr mess and get my branch landed? | 17:10 |
| rogpeppe | natefinch: sure | 17:10 |
| natefinch | rogpeppe: thanks | 17:10 |
| ahasenack | hm, since when does juju bootstrap perform a tool sync from amazon? | 17:10 |
| natefinch | rogpeppe: so, I think this is probably one problem: | 17:10 |
| natefinch | Repository tree (format: 2a) | 17:10 |
| natefinch | Location: | 17:10 |
| natefinch | shared repository: /home/nate/code | 17:10 |
| natefinch | repository branch: . | 17:10 |
| natefinch | Related branches: | 17:10 |
| ahasenack | http://pastebin.ubuntu.com/5981915/ | 17:10 |
| natefinch | push branch: bzr+ssh://bazaar.launchpad.net/~natefinch/juju-core/002-notbootstrapped/ | 17:10 |
| natefinch | parent branch: /home/nate/code/src/launchpad.net/juju-core-trunk | 17:10 |
| natefinch | submit branch: bzr+ssh://bazaar.launchpad.net/+branch/juju-core/ | 17:10 |
| rogpeppe | ahasenack: since quite recently, but i don't think that should happen when using --upload-tools | 17:11 |
| mgz | natefinch: what's the mess? | 17:11 |
| ahasenack | rogpeppe: yeah, and it's syncing the wrong tools even (1.12) | 17:12 |
| natefinch | mgz: see the paste above... that looks wrong, but I don't really know what it's supposed to look like, so maybe that's ok | 17:12 |
| rogpeppe | ahasenack: looks odd to me | 17:13 |
| mgz | natefinch: apart from submit branch (which doesn't really matter) it's fine? | 17:13 |
| rogpeppe | ahasenack: it should find the tools it's uploaded | 17:14 |
| natefinch | mgz: oh, ok. I thought the submit branch was what was tripping me up. | 17:14 |
| ahasenack | rogpeppe: fwiw I'm on raring, and requested a saucy bootstrap node, but it did say it was uploading a saucy tarball | 17:14 |
| ahasenack | I'm filing a bug | 17:14 |
| rogpeppe | ahasenack: +1 | 17:14 |
| natefinch | mgz: so, how do I land this thing? I merged from trunk, so I should be up to date | 17:15 |
| mgz | natefinch: see my "Landing bot active again" post to juju-dev for an easy way | 17:17 |
| mgz | in the archives, july 29th | 17:17 |
| natefinch | mgz: where's the archive? I wasn't on the mailing list at that point | 17:18 |
| mgz | lists.ubuntu.com | 17:18 |
| natefinch | mgz: nice, thanks | 17:19 |
| fwereade | sidnei, reviewed | 17:27 |
| rogpeppe | dimitern, fwereade, natefinch: fairly trivial change to utils/set: https://codereview.appspot.com/12872043 | 17:34 |
| sidnei | fwereade: uhm, not sure i get the comment about instance types without instance-storage? what are those? | 17:37 |
| === tasdomas_afk is now known as tasdomas | ||
| === tasdomas is now known as tasdomas_afk | ||
| rogpeppe | right, environs/ec2 tests pass. time to stop for the day. | 17:38 |
| rogpeppe | g'night all | 17:38 |
| natefinch | rogpeppe: LGTM'd | 17:40 |
| === BradCrittenden is now known as bac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!