| === slank is now known as slank_away | ||
| rogpeppe1 | davecheney: ping | 01:37 |
|---|---|---|
| davecheney | hey | 01:37 |
| davecheney | sorry, is it too late ? | 01:37 |
| rogpeppe1 | davecheney: no, it's good | 01:49 |
| jam | hi rogpeppe2 | 06:23 |
| jam | wallyworld: poke | 06:27 |
| wallyworld | jam: hi | 06:48 |
| jam | wallyworld: looks like you accidentally broke a test when your generate-config patch landed | 06:48 |
| wallyworld | oh :-( | 06:48 |
| jam | cmd/juju/main_test.go | 06:48 |
| jam | tests what commands are listed by 'juju help' | 06:48 |
| jam | and you added one. | 06:48 |
| wallyworld | ah bugger. ok, i'll fix it | 06:49 |
| jam | Pretty easy to fix, but you'll want to make sure you run "go test ./..." when landing to juju-core. (No bot to help us there) | 06:49 |
| wallyworld | i tried to but it hung | 06:49 |
| wallyworld | so i ran stuff by hand | 06:49 |
| jam | wallyworld: because of the mongo stuff? | 06:49 |
| wallyworld | yeah | 06:49 |
| jam | wallyworld: https://code.launchpad.net/~jameinel/juju-core/main-test/+merge/147023 | 06:49 |
| jam | (I still can't get lbox to work without giving unsupported protocol) | 06:49 |
| jam | wallyworld: do you have bigjools's ppa ? | 06:50 |
| wallyworld | no | 06:50 |
| jam | (I personally just put the mongo files into $GOPATH/bin, but the ppa is a good idea too) | 06:50 |
| jam | technically, it doesn't hang forever, it just takes 5min to timeout and FAIL :) | 06:51 |
| wallyworld | ok, i'll have to get all that working i think | 06:51 |
| jam | but that is for each test package that uses mongo, which is about 5-6, so it takes a pretty long time to run the whole suite. | 06:51 |
| jam | wallyworld: anyway, it is clear that dimitern didn't run the full test suite after merging either, since he landed code after you did. But it is something we need to remember as long as we are manual gatekeepers. | 06:58 |
| wallyworld | yeah | 06:58 |
| jam | (lbox submit *doesn't* run the test suite as near as I can see, which might be a reasonable way around it?) | 06:58 |
| wallyworld | if they didn't hang i would have | 06:59 |
| jam | wallyworld: install newer mongo :) | 06:59 |
| jam | then it won't hang | 06:59 |
| wallyworld | i'll have to get mongo sorted | 06:59 |
| jam | wallyworld: on the list bigjools mentioned how to disable it (echoing the right disable into a file in /etc), but it isn't something I know offhand. | 07:01 |
| jam | I'm personally happier not installing mongo and just having the binary in my $PATH | 07:01 |
| wallyworld | i'll search for it | 07:02 |
| jam | but I can appreciate the chain-of-authentication stuff | 07:02 |
| bigjools | echo ENABLE_MONGODB=no | sudo tee -a /etc/default/mongodb | 07:02 |
| wallyworld | thanks | 07:02 |
| bigjools | part payment for the cricket tickets to Australia C on Weds | 07:03 |
| jam | wallyworld: "Mongo packaging" is the thread on juju-dev if you need any of his other bits of wisdom. | 07:08 |
| wallyworld | ok, thanks | 07:09 |
| bigjools | how are you managing package versions? | 07:09 |
| jam | bigjools: how do we package juju-core? dave cheney :) | 07:09 |
| jam | He mentioned he just set up a daily build of juju-core | 07:10 |
| jam | I don't know much more than that for his final releases. | 07:10 |
| bigjools | well, I was thinking of go get | 07:10 |
| jam | bigjools: have you seen mythreads on it? Poorly | 07:10 |
| bigjools | I read them but that was before I starting understanding Go :) | 07:10 |
| bigjools | I got the impression it was bad | 07:10 |
| jam | bigjools: essentially "trunk always passes because we manage the race condition of updating the dependency and the master project at the same time" | 07:11 |
| jam | but old versions of trunk aren't guaranteed to pass (are expected not to build because we can't trivially rollback the version of the deps) | 07:11 |
| jam | once we are stable, we will probably go with a version number in the import string | 07:11 |
| jam | with the cost that if we have to bump stability, the branch we land on will change location. | 07:12 |
| bigjools | yeah, I was thinking about how to handle rollbacks etc | 07:12 |
| bigjools | I guess it will come when the language matures | 07:12 |
| jam | bigjools: essentially, we cannot do it easily, the tools don't support it, the powers that be don't want to write new tools. | 07:12 |
| jam | though I might be jaded in my interpretation of the situation. | 07:13 |
| jam | https://docs.google.com/a/canonical.com/document/d/1HaVHWyERiPOJgcIQ2W2jc9I7MZQ5OAVNB7m0nMr0oPw/edit#heading=h.dez8xb2t49nj was my attempt at trying to document it all | 07:13 |
| jam | I petered out a bit rather than just living with the status quo | 07:13 |
| bigjools | that's a recipe to have other tools reinvent the wheel and do it | 07:13 |
| bigjools | yeah I can understand | 07:13 |
| jam | bigjools: "Handling Active Dependencies in Go" is the rather large thread about it. https://groups.google.com/d/topic/golang-nuts/0avuiWURSQk/discussion is the only link I could find on golang-nuts | 07:14 |
| bigjools | thanks | 07:14 |
| jam | which is still "we could put the version in the import string" | 07:14 |
| jam | which breaks lots of other bits | 07:14 |
| jam | bigjools: specifically, the big problem with the import string, is that the *library* needs to also use the same import string | 07:15 |
| jam | otherwise they are 2 different packages | 07:15 |
| bigjools | yeah | 07:15 |
| jam | so when you do a release, you now have a different URL, and different library source code. | 07:15 |
| jam | and different place in your local dir | 07:15 |
| jam | so all your tools need to move over there, etc. | 07:15 |
| jam | so doing it for *every* bump of a lib that lands in juju-core | 07:15 |
| bigjools | this is the price for putting it in the import | 07:15 |
| jam | is too painful for devs | 07:15 |
| jam | bigjools: right, and there isn't an abstraction point in go | 07:16 |
| jam | They conflated them with probably some good intent (try not to repeat yourself) | 07:16 |
| jam | but then end up mixing essentially runtime information with build time information. | 07:16 |
| bigjools | yes | 07:16 |
| bigjools | but it's great if you want to work on trunk :) | 07:17 |
| jam | One proposal I mentioned was a tool that does the build-time information, and configures GOPATH (which is close to how LP does it with eggs and site.py) | 07:17 |
| bigjools | right | 07:17 |
| jam | bigjools: except for landing change to goose's trunk breaks juju-core from building. | 07:17 |
| jam | unless you land patches "simultaneously" | 07:17 |
| jam | we need to add 2-phase-commit to bzr :) | 07:17 |
| bigjools | incompatible goose changes or some other reason? | 07:18 |
| jam | bigjools: change anything that isn't directly source compatible. | 07:18 |
| jam | 'go get' always grabs the latest tip of both branches. | 07:18 |
| jam | so, rename a public variable, etc. | 07:18 |
| bigjools | right - I was wondering if it was some language internal to do with compiling it | 07:18 |
| jam | which truly isn't "stable" | 07:19 |
| jam | but is very much in the "we don't know what the ideal API is yet, so let us not have cruft *before* we hit 1.0" | 07:19 |
| bigjools | do we know how Google manages this problem? | 07:19 |
| jam | bigjools: the thread above mentions 'goven' which is the CVS "vendor" model. | 07:20 |
| jam | Track an upstream branch in your own repository | 07:20 |
| jam | and use a tool to rename all of your "import launchpad.net/goose" code to be "import launchpad.net/juju-core/launchpad.net/goose" | 07:20 |
| bigjools | I guess repository revnos become super important | 07:20 |
| jam | bigjools: not quite sure I follow | 07:21 |
| jam | Essentially you just put all possibly-unstable dependencies into your source tree. | 07:21 |
| bigjools | if the packages don't have inherent versioning, you need to rely on repo versions to know what you have | 07:21 |
| jam | with some tool helpers to make it a bit easier to update them to newer versions when you choose. | 07:21 |
| bigjools | or am I missing something? | 07:21 |
| jam | bigjools: go get doesn't have repo versions, it has repo locations. | 07:22 |
| jam | So while *I* would have a tool more like launchpad's sourcedeps which lets you say "use launchpad.net/foobar@1234" | 07:22 |
| bigjools | yes, but can you not fix the revno? | 07:22 |
| jam | bigjools: you cannot put the revno into go get | 07:22 |
| bigjools | yes, I mean pulling manually | 07:22 |
| jam | bigjools: you can do your branches manually and not use 'go get -u' | 07:23 |
| bigjools | or does it always refresh the branches? | 07:23 |
| jam | bigjools: -u always refreshes the branches, but you could do all the work yourself | 07:23 |
| bigjools | ok | 07:23 |
| jam | with the major caveat that nobody else would do that until everything broke | 07:23 |
| bigjools | this is messy :( | 07:23 |
| jam | so you certainly can make your local development "work" | 07:23 |
| jam | if I grab your code, it will break until I find your magic sauce. | 07:23 |
| jam | which was the objection to writing a tool that did it | 07:23 |
| jam | because then you need this new tool. | 07:24 |
| jam | So version numbers in the import paths is sort of the way to go, except we aren't stable enough to pay the cost of creating a new branch for every change we want to land in juju-core. | 07:24 |
| bigjools | right | 07:24 |
| wallyworld | but even with version numbers in imports, you still pull from tip :-( | 07:25 |
| bigjools | ok, EOD here. Bye all. | 07:25 |
| jam | wallyworld: which is why you have to only use 1 branch per version you want to land | 07:26 |
| jam | essentially, make a full release for anything you want to pull into juju-core | 07:26 |
| wallyworld | which sucks :-( | 07:26 |
| jam | Which is heavyweight but feasible once we are stable. | 07:26 |
| wallyworld | but anyway, we've had that discussion | 07:26 |
| * wallyworld late for soccer, back later | 07:27 | |
| jam | wallyworld: good luck! | 07:27 |
| TheMue | fwereade_: Hiya and thx for the review. Regarding the non-existing path my solution creates nothing, so maybe less cost. But your is more elegant so that I'll take it. | 09:38 |
| fwereade_ | note also that your solution doesn't address the possibility that a file might be created after you check but before you run the test | 09:39 |
| fwereade_ | TheMue, thanks :) | 09:39 |
| TheMue | fwereade_: Yeah, the little rest risk would exist, you're right. Even if the chance would be very low. ;) | 09:43 |
| fwereade_ | TheMue, million-to-one chances come up most days ;) | 09:43 |
| TheMue | fwereade_: If one is running the tests each day and every minute, yes. :D | 09:44 |
| fwereade_ | TheMue, forgive my professional paranoia ;) | 09:44 |
| TheMue | fwereade_: I appreciate it. | 09:46 |
| TheMue | fwereade_: So I will now take your feedback and submit afterwards, so that we don't have those two parallel branches. | 09:47 |
| fwereade_ | TheMue, great -- tyvm, and thank you for bearing with me on these | 09:48 |
| TheMue | fwereade_: I've got to thank you, great results need good reviews. | 09:51 |
| * fwereade_ blushes | 09:51 | |
| TheMue | :D | 09:51 |
| fwereade_ | TheMue, rogpeppe2, jam, mgz: is juju-core also failing to build for you? I think I have the latest goose; it's complaining about identity.AuthMode and fip.InstanceId | 10:04 |
| jam | fwereade_: the failure wasn't related to that. I'm pretty sure you need to cd ../goose; bzr pull --remember lp:goose | 10:12 |
| jam | We moved where trunk was, so refreshing it should get you the latest goose. | 10:12 |
| jam | "lp:goose" didn't change | 10:12 |
| jam | but the exact branch it mapped to did, and "go get" expands the branch (I think) | 10:12 |
| fwereade_ | jam, thanks, that seems to have sorted it; I did try a go get -u, (and also tried a bzr update) then came complaining here | 10:13 |
| wallyworld | jam: what problem were you having with reitveld - for some reason it all of a sudden won't authorise me anymore when I use lbox. is this what you saw? | 11:09 |
| dimitern | wallyworld: the authorization expires after 30 days I think - it happened to me before | 11:09 |
| wallyworld | i typed in my password and user id | 11:09 |
| dimitern | wallyworld: just sign in in rietveld again and authorize your google account to use it | 11:10 |
| dimitern | wallyworld: and then use lbox again | 11:10 |
| wallyworld | i signed in via the command line but didn;'t authorise google | 11:10 |
| wallyworld | i'll try that thanks | 11:10 |
| dimitern | jam, mgz: standup? | 11:34 |
| mgz | ne\rly there... | 11:35 |
| TheMue | lunchtime | 11:45 |
| rogpeppe2 | fwereade_: does this error just imply that the charm isn't in the charm store? | 12:38 |
| rogpeppe2 | 2013/02/07 12:37:35 JUJU juju deploy command failed: cannot get latest charm revision: charm info errors for "cs:precise/logall-subordinate": entry not found | 12:38 |
| === rogpeppe2 is now known as rogpeppe | ||
| rogpeppe | fwereade_: hmm, scratch that, i'm not using the right url. | 12:44 |
| rogpeppe | fwereade_: it's interesting, the charm store doesn't print urls that are acceptable to go juju | 12:45 |
| rogpeppe | go juju rejects this as invalid: ~ju-jistics-hackers:precise/logall-subordinate | 12:45 |
| rogpeppe | it also rejects cs:~ju-jistics-hackers:precise/logall-subordinate | 12:45 |
| niemeyer | Hello world! | 12:51 |
| rogpeppe | niemeyer: yo! | 12:51 |
| rogpeppe | niemeyer: i just discovered that the charm URLs printed by the charm store aren't valid for use with go juju. is that a problem on our side or theirs? | 12:52 |
| niemeyer | rogpeppe: Slightly hard to tell given that summary :-) | 13:08 |
| rogpeppe | niemeyer: here's an example of a URL shown by the charm store web site: ~ju-jistics-hackers:precise/logall-subordinate | 13:08 |
| niemeyer | rogpeppe: That's not a valid URL | 13:09 |
| rogpeppe | niemeyer: that's what i thought | 13:09 |
| rogpeppe | niemeyer: i wonder if py juju is accepting it though | 13:10 |
| niemeyer | rogpeppe: I don't think so | 13:10 |
| niemeyer | rogpeppe: This is unlikely anything else we've ever talked about | 13:10 |
| niemeyer | rogpeppe: URLs are prefixed by lp: | 13:10 |
| niemeyer | Erm, sorry | 13:10 |
| niemeyer | cs: | 13:10 |
| rogpeppe | niemeyer: yeah, but it's invalid even when prefixed by cs: | 13:10 |
| niemeyer | rogpeppe: Yeah, the : there should be / | 13:11 |
| rogpeppe | niemeyer: yup | 13:11 |
| rogpeppe | niemeyer: i'll try to find the appropriate place to raise an issue | 13:11 |
| niemeyer | rogpeppe: Thanks | 13:12 |
| niemeyer | rogpeppe: Good catch | 13:12 |
| jam | wallyworld: note that the types will now have methods on them that they didn't before, so it isn't that much 'less' poluted (imo). If I could, I would make them private, but then JSON couldn't unmarshal into them. | 13:13 |
| jam | I wasn't worried about pollution, because I thought these were supposed to be the types-for-json objects not the public-api objects. | 13:13 |
| wallyworld | jam: the state that the user can access though is cleaner | 13:13 |
| wallyworld | at the moment, the objects eg Entity, ServerDetail etc are used in juju-core | 13:15 |
| wallyworld | so they are being used as the public api objects for better or worse | 13:16 |
| rogpeppe | niemeyer: https://bugs.launchpad.net/charmworld/+bug/1118351 | 13:17 |
| _mup_ | Bug #1118351: Charm URLs shown with invalid URLs in search <charmworld:New> < https://launchpad.net/bugs/1118351 > | 13:17 |
| === slank_away is now known as slank | ||
| Pavel_ | Hi guys. Is there a way that I can add a local repository to juju-gui so I will be able to deploy my local charms directly from it? | 14:46 |
| hazmat | Pavel_, not yet | 14:58 |
| hazmat | Pavel_, we've been thinking to support local charms, we'll have the user run a program on their machine to expose the local repo via api on localhost that the gui can connect back to | 14:59 |
| Pavel_ | Can't it just accept e.g. git repo as an setting and fetch it to it's own instance and then look through it? | 15:01 |
| hazmat | Pavel_, that's much less generic.. we'd have to support arbitrary numbers of arbitrary vcs, and authenticated access to those.. | 15:06 |
| hazmat | to get to equiv functionality | 15:07 |
| Pavel_ | yeah seems like it's not best option | 15:12 |
| Pavel_ | but still if you want to run juju on the same node as juju bootstrap, then you already have this local repo available | 15:14 |
| Pavel_ | *juju gui | 15:14 |
| Pavel_ | but of course it's not common case | 15:14 |
| mramm | oops, lost track of time writing | 15:16 |
| Pavel_ | And isn't "juju scp" an another option? Can't you copy local repo from juju bootstrap node to juju GUI node? | 15:17 |
| Pavel_ | Sorry if I get something wrong | 15:18 |
| hazmat | Pavel_, there isn't a local repo per se on disk for either the bootstrap or gui node. the gui is searching through rest api endpoints of a charm store frontend, which is what we should replicate in the locally run program. the env has a cache of deployed service charms, but those are in provider storage, not on any given machine. ie there is no repo on disk to simply copy files to. | 15:33 |
| Pavel_ | Yes, I understand. But do you think that replicating API is easier then reading repo from a local storage? | 15:40 |
| hazmat | Pavel_, simple answer yes.. what's local storage in a multi-node ha system? | 15:48 |
| Pavel_ | but juju bootstrap is always one node, isn't it? | 15:48 |
| hazmat | Pavel_, that's being worked on | 15:48 |
| Pavel_ | hazmat, hot it | 15:49 |
| Pavel_ | *got ) | 15:49 |
| hazmat | i agree though at some point we'll have to explore answering questions from what local charms the environment has deployed .. but even then wouldn't be answering questions from disk. its not simply reading the charms on disk.. not just because there not on disk, but because its quite a rich search interface.. ie you can do full text and fielded queries like requires:mysql and conjunctions. | 15:51 |
| hazmat | speaking of which i was looking around for full text solutions for golang.. i found some n-gram/codesearch content.. but afaics there isn't any equivalent to xapian/lucene in golang.. best i could find was sqlite fts. | 15:52 |
| Pavel_ | hazmat, I think that usually all you want is just to run more instances of existing services or deploy one which name you already know. | 15:57 |
| hazmat | Pavel_, that's fair.. but the search also helps drive richer ui interfaces, suggested relations, discovery, etc. | 16:00 |
| Pavel_ | hazmat, but for local repo you could have simplier version of this | 16:01 |
| Pavel_ | hazmat, actually you already know what is there and what you want to deploy | 16:01 |
| Pavel_ | Generally I'm newbie in using juju, but my vision is that it can really play well for deploying domain based charms written for particular service. | 16:02 |
| hazmat | Pavel_, yes it could be simpler and likely will be, but local doesn't mean the deployer wrote it or that the repo doesn't contain lots of charms, ie. search is still useful. hmmm.. i think i see what your saying for the use case though and why the local program for local charms doesn't suffice for it | 16:08 |
| hazmat | effectively you want to put local charms to the env, and have them available for deploy in the gui | 16:08 |
| Pavel_ | yep | 16:09 |
| hazmat | Pavel_, sounds good | 16:33 |
| Pavel_ | I really miss this feature | 16:36 |
| Pavel_ | one more question, is there a way to set user name when run juju debug-hooks ? | 16:38 |
| Pavel_ | I get ssh error when try doing this | 16:38 |
| hazmat | Pavel_, no.. it should be using the same key used to populate the env.. default it sniffs and injects the public key, but it can be specificied explicitly in environments.yaml as well .. it always goes to the ubuntu user which juju injects the public key as authorized key.. also this sort of question is better on #juju | 16:46 |
| Pavel_ | ah, ok | 16:47 |
| === slank is now known as wedgwood | ||
| rogpeppe | afk for a little | 17:27 |
| rogpeppe | back | 17:42 |
| dimitern | rogpeppe: quick question? | 18:14 |
| rogpeppe | dimitern: ask away! | 18:15 |
| dimitern | rogpeppe: what do I need to support for := range over my own type? | 18:15 |
| rogpeppe | dimitern: you can't do that | 18:15 |
| rogpeppe | dimitern: range always ranges over maps, slices or channels | 18:15 |
| dimitern | rogpeppe: really? damn.. | 18:15 |
| rogpeppe | dimitern: what kind of type is it? | 18:16 |
| dimitern | rogpeppe: so I need something like a while loop with Next() | 18:16 |
| rogpeppe | dimitern: there are various possibilities for iteration | 18:16 |
| rogpeppe | dimitern: it totally depends what the semantics of your type are | 18:16 |
| dimitern | rogpeppe: well I'm trying to replace an embedded url.Values and provide the same interface - Add, Del, Set, Encode, etc. and still be able to iterate over | 18:17 |
| rogpeppe | dimitern: do you know in advance how many elements there are? | 18:17 |
| rogpeppe | dimitern: what semantics do you want to add? | 18:17 |
| dimitern | rogpeppe: because I need range to iterate in the order added and url.Values is map[string][]string | 18:17 |
| rogpeppe | dimitern: why not just provide a method that returns a sorted slice of all the entries in the map? | 18:18 |
| dimitern | rogpeppe: i.e. f.Add(x, ..); f.Add(y, ..) -> range x, then y | 18:18 |
| dimitern | rogpeppe: hmm yeah, that could work | 18:18 |
| rogpeppe | dimitern: you could just return the keys | 18:19 |
| rogpeppe | dimitern: and leave your type as a map | 18:19 |
| dimitern | rogpeppe: but not good enough - I don't need them sorted, but in the order added | 18:19 |
| rogpeppe | dimitern: out of interest, what's this to be used for? | 18:19 |
| dimitern | rogpeppe: maybe leave the embedded and override Add to keep ordered slice of keys aside and a method Keys() to return them in proper order | 18:20 |
| dimitern | rogpeppe: because openstack is sensitive with the order in which you specify multiple value filters | 18:20 |
| dimitern | rogpeppe: so status=A&status=B is not the same as status=B&status=A | 18:21 |
| rogpeppe | dimitern: ah | 18:21 |
| rogpeppe | dimitern: so it's not like ec2 that numbers all attributes sequentially? | 18:21 |
| dimitern | rogpeppe: no, it's a weird lax url encoded stuff with duplicates, but some logic to parse them in order | 18:22 |
| rogpeppe | dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff | 18:22 |
| rogpeppe | dimitern: that's quite bad | 18:23 |
| rogpeppe | dimitern: what a shitty interface | 18:23 |
| rogpeppe | dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ? | 18:24 |
| dimitern | wow, my machine died on me | 18:27 |
| rogpeppe | dimitern: :-| | 18:27 |
| rogpeppe | dimitern: what was the last message you saw from me? | 18:28 |
| dimitern | rogpeppe: can't see - had to cold boot | 18:28 |
| rogpeppe | dimitern: you need a better irc client :-) | 18:28 |
| rogpeppe | here are the last few things is said | 18:29 |
| rogpeppe | i said! | 18:29 |
| rogpeppe | 18:22:37] <rogpeppe> dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff | 18:29 |
| rogpeppe | [18:23:36] <rogpeppe> dimitern: that's quite bad | 18:29 |
| rogpeppe | [18:23:49] <rogpeppe> dimitern: what a shitty interface | 18:29 |
| rogpeppe | [18:24:46] <rogpeppe> dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ? | 18:29 |
| dimitern | rogpeppe: right, so the difference is this | 18:29 |
| dimitern | rogpeppe: I'll paste my code to see | 18:29 |
| dimitern | rogpeppe: http://paste.ubuntu.com/1621741/ | 18:30 |
| rogpeppe | dimitern: oh BTW, there shouldn't be a problem with status=A&status=B - the same attribute is used both times | 18:30 |
| dimitern | rogpeppe: the problem is they are combined | 18:31 |
| dimitern | rogpeppe: oh... you know what, I think you're right - it's simpler | 18:31 |
| rogpeppe | dimitern: yeah, i don't think you're ranging over a map there | 18:31 |
| dimitern | rogpeppe: I managed to debug the name gets replaced by the last value specified, but for status wasn't that obvious | 18:32 |
| rogpeppe | dimitern: all the names are still available | 18:32 |
| rogpeppe | dimitern: that's why it's map[string][]string | 18:32 |
| dimitern | rogpeppe: my original thought was specifying status twice will get me both statuses | 18:32 |
| rogpeppe | dimitern: (note the []string) | 18:32 |
| rogpeppe | dimitern: it should do, yes | 18:32 |
| dimitern | rogpeppe: but my tests so far show: | 18:33 |
| rogpeppe | dimitern: i mean... what? | 18:33 |
| rogpeppe | dimitern: it depends what level you're talking about | 18:33 |
| dimitern | rogpeppe: S=A&S=B -> 0 (assuming 3 servers in A) | 18:33 |
| dimitern | rogpeppe: S=B&S=A -> 3; S=X&S=Y&S=A -> 3; S=X&S=A&S=Y -> 0 | 18:34 |
| rogpeppe | dimitern: those are the semantics that openstack gives you? | 18:34 |
| dimitern | rogpeppe: it's very frustrating to actually create several machines with different status to test this properly | 18:34 |
| dimitern | rogpeppe: those are my findings after running a lot of queries with filters against canonistack | 18:35 |
| rogpeppe | dimitern: so it's just ignoring all but the last value for a given attribute, right? | 18:35 |
| dimitern | rogpeppe: and the problem is, in juju you'd like to get all machines in either build or active, but this seems impossible with as single API call | 18:35 |
| dimitern | rogpeppe: seems so yes | 18:36 |
| rogpeppe | dimitern: they could've learned something from ec2's filtering semantics | 18:36 |
| dimitern | rogpeppe: i tried to replicate ec2 way, but i guess we'll have to get only active machines and until the status changes from build to active, Instances() won't return anything | 18:36 |
| rogpeppe | dimitern: yeah, sounds like you need two queries | 18:36 |
| rogpeppe | dimitern: and combine the results of both | 18:37 |
| rogpeppe | dimitern: you can run 'em both concurrently though, so it shouldn't be much slower | 18:37 |
| dimitern | rogpeppe: yes, unless getting only active suffices | 18:37 |
| rogpeppe | dimitern: so... i don't see that there's any particular difficulty here | 18:37 |
| rogpeppe | dimitern: we don't care about map ordering | 18:38 |
| dimitern | rogpeppe: yeah | 18:38 |
| dimitern | rogpeppe: I wish I could've seen that yesterday more clearly :) | 18:38 |
| dimitern | rogpeppe: and to actually test whether in fact multiple status filters work at all | 18:39 |
| rogpeppe | dimitern: to implement the double you can just have a function: func GetLastValue(v url.Values, attr string) string {x := v[attr]; if len(x) > 0 {return x[len(x)-1]}; return ""} | 18:39 |
| dimitern | rogpeppe: is it important to get pending machines from the provider as well? even with the eventual consistency attempts/retries? | 18:39 |
| rogpeppe | dimitern: yes | 18:40 |
| dimitern | rogpeppe: why? | 18:40 |
| rogpeppe | dimitern: because we assume that if we've called StartInstance we can retrieve information about it soon afterwards | 18:40 |
| rogpeppe | dimitern: if openstack is anything like ec2, pending machines can remain pending for quite a long time | 18:41 |
| dimitern | rogpeppe: if it's only about getting result out of StartInstance, you always get this | 18:42 |
| rogpeppe | dimitern: what's the significance of "build" and "active" with regard to juju, BTW? | 18:42 |
| dimitern | rogpeppe: and it's correct, the problem could be if you want to list them later | 18:42 |
| rogpeppe | dimitern: exactly | 18:42 |
| rogpeppe | dimitern: or get an Instance | 18:42 |
| rogpeppe | dimitern: from the instance id | 18:42 |
| rogpeppe | dimitern: what's the issue you have with returning pending instances? | 18:43 |
| dimitern | rogpeppe: build means basically booting, setting up network, etc., which becomes available shortly before the machine switches to active | 18:43 |
| dimitern | rogpeppe: getting instance by id is again not a problem | 18:43 |
| dimitern | rogpeppe: only Instances() and AllInstances() are affected | 18:44 |
| dimitern | rogpeppe: which will use the filtering and ideally do it with a single API call, filtering by inst name (environment) and active status | 18:45 |
| dimitern | rogpeppe: if you need a specific instance and you know it's id you can get it directly, no filtering involved | 18:45 |
| rogpeppe | dimitern: i think only AllInstances is affected | 18:46 |
| dimitern | rogpeppe: the idea of filtering arose from the need to get only this environment's machines (by name) - so both Instances() and AllInstances() use it | 18:47 |
| rogpeppe | dimitern: Instances only does it so it doesn't return machines which have been stopped | 18:48 |
| dimitern | rogpeppe: but how about the ones about to become active? | 18:49 |
| rogpeppe | dimitern: yeah, it needs to return those | 18:49 |
| rogpeppe | dimitern: as far as juju is concerned, they're active already, just not ready. | 18:49 |
| dimitern | rogpeppe: ok I can do it in 2 goroutines then, fetching both active and build and returning the merged | 18:50 |
| dimitern | rogpeppe: the thing is, machines in build state cannot be tackled the same as active ones | 18:50 |
| rogpeppe | dimitern: yup. or, even better, just don't filter by status at all | 18:50 |
| rogpeppe | dimitern: and filter that client side | 18:50 |
| dimitern | rogpeppe: some things fail (like assigning a floating IP) | 18:51 |
| dimitern | rogpeppe: that's even better actually - I'll just filter out the ones with bad status | 18:51 |
| rogpeppe | dimitern: yup | 18:51 |
| dimitern | rogpeppe: the problem is you can have 100K machines to process there | 18:51 |
| rogpeppe | dimitern: we only do the filtering server-side in ec2 'cos it's easy to do | 18:51 |
| rogpeppe | dimitern: that's true of AllInstances in general | 18:52 |
| rogpeppe | dimitern: i don't think returning dead machines is going to add too much load | 18:52 |
| dimitern | rogpeppe: actually the machines that need filtering will be a lot less than the active ones | 18:53 |
| rogpeppe | dimitern: exactly | 18:53 |
| dimitern | rogpeppe: ok then, I'll filter client-side for status | 18:53 |
| rogpeppe | dimitern: +1 | 18:53 |
| dimitern | rogpeppe: thanks :) it really helped me clear it up for myself | 18:54 |
| rogpeppe | dimitern: then you can ignore the whole url.Values thing :-) | 18:54 |
| rogpeppe | dimitern: np, it's a pleasure to help | 18:54 |
| dimitern | rogpeppe: yeah, or at least make it much simpler | 18:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!