| === robbiew-afk is now known as robbiew | ||
| niemeyer | Alright.. that was a long day | 02:59 |
|---|---|---|
| niemeyer | Have a good night all | 02:59 |
| niemeyer | Or a good day, I guess | 02:59 |
| * niemeyer => bed | 02:59 | |
| === negronjl` is now known as negronjl | ||
| niemeyer | Good morning lads | 10:14 |
| fwereade | niemeyer: heyhey, didn't see you there :) | 10:39 |
| niemeyer | fwereade: Hey man! | 10:40 |
| fwereade | niemeyer: thanks for the reviews, much appreciated | 10:40 |
| niemeyer | fwereade: No worries, I hope it all makes sense | 10:40 |
| fwereade | niemeyer: yeah, some excellent points | 10:40 |
| fwereade | niemeyer: I'm trying to figure out the right shape for the zookeeper-finding stuff, and nothing's really making me happy so far, but I'll find something | 10:41 |
| niemeyer | fwereade: Cool, please let me know if you want to brainstorm on something there | 10:54 |
| hazmat | g'monring | 11:36 |
| hazmat | morning | 11:36 |
| hazmat | ensemble talk at local python user group went really well about 25 folks on hand | 11:55 |
| niemeyer | hazmat: Morning! | 11:57 |
| niemeyer | hazmat: Oh.. good interest? | 11:57 |
| hazmat | niemeyer, indeed, several folks doing cloud based deployments, almost 10 had used puppet/chef in the past... i was surprised how many python old-timers where there. had some good talks with jim fulton (cto zope corp) and some others afterwards | 11:59 |
| fwereade | hazmat: cool :) | 12:00 |
| niemeyer | hazmat: Wow, sweet | 12:01 |
| niemeyer | hazmat: Was that a Linux user group, or a Pythonn one? | 12:01 |
| niemeyer | hazmat: Or a * user group? :) | 12:02 |
| hazmat | still trying to track one of the attendees down, i want to talk to some more, he had alot of sysadmin chops on 1k scale deployments. | 12:02 |
| hazmat | niemeyer, python user group, by old-timer i meant 10+ years of python. | 12:02 |
| niemeyer | hazmat: Sweet | 12:03 |
| niemeyer | hazmat: Yeah, would be good to have that kind of contact | 12:03 |
| hazmat | lots of macbook pros in the room.. but i said.. ubuntu is only a vm away ;-) | 12:03 |
| hazmat | although i guess we have a macports install for ensemble, albeit frozen | 12:03 |
| fwereade | niemeyer: btw, I think I have a functiony approach that works quite well, but naming is a bit of an issue; I've gone with find_zookeepers_core (that takes a provider and a callback that should turn an instance id into a machine, or raise the appropriate exception) | 12:04 |
| fwereade | but "_core" doesn't feel quite right | 12:04 |
| fwereade | "_base" is too overloaded IMO | 12:04 |
| fwereade | and just "find_zookeepers" forces me into "as" imports | 12:05 |
| fwereade | which suck | 12:05 |
| fwereade | heh, as soon as I speak in public I think of something better | 12:05 |
| niemeyer | fwereade: Aha, I see | 12:09 |
| niemeyer | fwereade: Change the other ones, then | 12:10 |
| niemeyer | fwereade: find_orchestra_zookeepers | 12:10 |
| niemeyer | fwereade: Which will take less arguments, I suppose | 12:10 |
| fwereade | niemeyer: I guess, but then we have the namespace repetition | 12:10 |
| fwereade | niemeyer: ...and I now realise that there's an uncomfortable overlap between what I have and some other ec2 code | 12:11 |
| fwereade | niemeyer: I think it was always there, but it's just become obvious | 12:11 |
| fwereade | niemeyer: more thinking required | 12:11 |
| fwereade | incidentally, any objections to introducing MachineNotFound and MachinenotReady errors? | 12:12 |
| hazmat | niemeyer, is there an equivalent of virtualenv for goinstall ? | 12:12 |
| niemeyer | hazmat: There's no need to.. | 12:13 |
| niemeyer | hazmat: It won't install anything on your system | 12:14 |
| niemeyer | hazmat: Just define something like "export GOPATH=~/gopath" | 12:14 |
| niemeyer | hazmat: Everything will be there | 12:14 |
| niemeyer | fwereade: Agreed regarding repetition.. but there's no way to avoid it, one way or another | 12:15 |
| niemeyer | fwereade: E.g. | 12:15 |
| niemeyer | fwereade: We can also call the other side "find_zookeepers_common" | 12:15 |
| niemeyer | fwereade: Instead of "_core".. | 12:15 |
| niemeyer | fwereade: Which is repeating the "common" namespace | 12:15 |
| fwereade | niemeyer: well, my thought was that actually the only provider-specific bit is a function that takes an instance id and returns a machine or raises an error | 12:16 |
| niemeyer | fwereade: So either: 1) We rename on import, or 2) We add the namespace so we can use both in the same context | 12:16 |
| niemeyer | fwereade: 2) sounds better | 12:16 |
| niemeyer | fwereade: I have no preference in terms of which side to rename | 12:16 |
| fwereade | niemeyer: but I've realised there's actually no need to have more than one find_zoookeepers function anyway | 12:17 |
| niemeyer | fwereade: find_zookeepers_common or find_orchestra_zookeepers sounds ok | 12:17 |
| niemeyer | fwereade: How so? | 12:17 |
| fwereade | niemeyer: the only difference between ec2 and orchestra is the callback which determines whether an instance id is good enough to turn into a machine and return | 12:18 |
| fwereade | niemeyer: so all I need to do is come up with a good name for *that*, and somehow deal with the fact that the code is very similar to existing code that turns instance_ids into machines | 12:19 |
| niemeyer | fwereade: Hah, neat | 12:19 |
| niemeyer | fwereade: Woohay composition | 12:20 |
| niemeyer | :-) | 12:20 |
| fwereade | niemeyer: yeah, it's rather pleasing | 12:20 |
| niemeyer | fwereade: Testing also gets a lot easier | 12:20 |
| fwereade | niemeyer: ...potentially :) | 12:21 |
| === otubo is now known as otubo[AFK] | ||
| fwereade | niemeyer: I've noticed at least one place where we do just mock out our own code, and trust that the result of composing verified pieces is itself effectively verified, but I understood you had some pretty serious reservations with that approach | 12:22 |
| fwereade | niemeyer: that statement makes me think I may not have fully grasped your position | 12:23 |
| fwereade | niemeyer: certainly, I can test the common one very nicely, but I'm not sure what level of testing you'd prefer for the actual provider implementations | 12:25 |
| niemeyer | fwereade: It's more likely that the code went in unnoticed.. I'm pretty sure you understand my position well | 12:26 |
| fwereade | niemeyer: hah, ok then :) | 12:26 |
| fwereade | niemeyer: you'll be pleased to know it is verified separately as well, as I recall | 12:27 |
| fwereade | niemeyer: but I'll make a note to kick it about a bit next time I notice it | 12:27 |
| niemeyer | fwereade: I've seen such "that's how it should be" cross-mocking test cases pass gracefully with an implementation that exploded in practice | 12:27 |
| fwereade | niemeyer: likewise ;) | 12:28 |
| fwereade | niemeyer: I have fuzzy ideas about a fruitful middle ground, but it's a total derail now, maybe I'll get around to writing them up properly at some point though | 12:29 |
| niemeyer | fwereade: mocker has means to avoid some of the pain, but it's still very far from perfect | 12:29 |
| niemeyer | fwereade: (it actually checks interfaces) | 12:29 |
| fwereade | niemeyer: I saw that, and liked it | 12:32 |
| fwereade | niemeyer: but indeed, no silver bullet :) | 12:35 |
| niemeyer | fwereade: Yeah, "takes the same number of arguments" is far from a valid guarantee | 12:36 |
| fwereade | please confirm: all I need to do to get cobbler-find-zookeepers back in the queue is to mark it "needs review" again | 13:25 |
| niemeyer | fwereade: That's right | 13:29 |
| fwereade | niemeyer: cheers | 13:29 |
| fwereade | niemeyer: cobbler-launch-machine review [7] | 13:31 |
| fwereade | Why are we "fixing" a dictionary in-flight rather than producing | 13:31 |
| fwereade | the right one? | 13:31 |
| fwereade | ...please expand | 13:31 |
| fwereade | is it just that you'd rather build the dictionary up from scratch? | 13:32 |
| niemeyer | fwereade: No.. passing untyped blobs of data is already not ideal by nature | 13:33 |
| fwereade | niemeyer: certainly | 13:34 |
| niemeyer | fwereade: The logic there goes one step further by moving keys around within the dicionary | 13:34 |
| niemeyer | dictionary | 13:34 |
| niemeyer | fwereade: Why is it doing so? | 13:34 |
| fwereade | niemeyer: because the expected format of machine_data doesn't match the expected format of the args to format_cloud_ini | 13:35 |
| fwereade | niemeyer: I seem to recall the ec2 provider mungs it a bit as well | 13:35 |
| niemeyer | fwereade: Why? | 13:35 |
| niemeyer | fwereade: It's clear that we do it.. what's not clear is why we do it | 13:36 |
| fwereade | niemeyer: ha :) | 13:36 |
| fwereade | niemeyer: I have no idea | 13:36 |
| niemeyer | fwereade: So let's not do it | 13:36 |
| fwereade | niemeyer: sounds good :) | 13:37 |
| fwereade | niemeyer: otherwise, re gzipping the data | 13:37 |
| fwereade | niemeyer: you just don't feel there's any call to go gzipping things until we're using a lot more space? | 13:38 |
| fwereade | niemeyer: or is there some other consideration? | 13:38 |
| niemeyer | fwereade: No, that's all really.. it feels like added complexity without benefit | 13:42 |
| niemeyer | fwereade: I suspect the ungzipped content should fit within a single ip packet.. given that and how rare the event is, it sounds unnecessary | 13:42 |
| fwereade | niemeyer: yep, and we can always reinstate it if it becomes a problem :). | 13:43 |
| fwereade | niemeyer: I think I know what I'm doing now then :) | 13:43 |
| niemeyer | fwereade: It won't become a problem.. who would need more than 640k of memory | 13:43 |
| fwereade | niemeyer: :D | 13:43 |
| niemeyer | ;-) | 13:43 |
| fwereade | niemeyer: incidentally: there's no way to fix the incorrect prereq without resubmitting the mp, is there? | 13:45 |
| niemeyer | fwereade: I thought it was just a matter of editing it.. but I've never tried to be honest | 13:46 |
| fwereade | niemeyer: I see no editability | 13:47 |
| fwereade | niemeyer: not to worry, resubmissions have previous-version links IIRC | 13:47 |
| RoAkSoAx | fwereade: howdy!! | 13:50 |
| fwereade | RoAkSoAx: heyhey | 13:50 |
| fwereade | RoAkSoAx: how's life? | 13:51 |
| RoAkSoAx | fwereade: good good, how about yours? | 13:51 |
| fwereade | RoAkSoAx: yeah, I just had a nice "I'm being paid to sit at home and write code!" moment :) | 13:51 |
| fwereade | RoAkSoAx: and stuff's making its way into trunk | 13:51 |
| RoAkSoAx | fwereade: hehehe cool for both | 13:52 |
| RoAkSoAx | fwereade: did you receive my email? | 13:52 |
| fwereade | RoAkSoAx: I saw; I probably won't get onto integrating them today I'm afraid | 13:53 |
| fwereade | RoAkSoAx: didn't see what branch they were in though... | 13:53 |
| RoAkSoAx | fwereade: that's fine, I just have a few things to fix first | 13:53 |
| RoAkSoAx | fwereade: haven't put them yet, i'm preparing it now | 13:53 |
| fwereade | RoAkSoAx: ah cool | 13:53 |
| RoAkSoAx | fwereade: but this is the result: http://pastebin.ubuntu.com/657941/ | 13:54 |
| fwereade | RoAkSoAx: sweeet :D | 13:54 |
| RoAkSoAx | fwereade: ok so take a look mat this first, and then we can discuss it as there's a few things to discuss: http://paste.ubuntu.com/657943/ | 13:56 |
| fwereade | RoAkSoAx: ok, just need a quick break before conversation, back in a mo | 14:00 |
| RoAkSoAx | fwereade: sure I'm ghonna prepare some tea ;) | 14:00 |
| fwereade | RoAkSoAx: ready when you are | 14:03 |
| === otubo[AFK] is now known as otubo | ||
| RoAkSoAx | fwereade: do you have any thoughts about it first? | 14:08 |
| fwereade | RoAkSoAx: looks broadly sensible, I think, I've got my eye on the existing structure in ec2 for possible rearrangement, but it's really helpful that it matches closely | 14:09 |
| RoAkSoAx | fwereade: its pretty much exactly the same as the ec2 classes but with minor changes | 14:10 |
| fwereade | RoAkSoAx: yep, exactly | 14:10 |
| RoAkSoAx | fwereade: 1. in cobbler.py I've added describe_systems (instead of using describe_system). I've done this to be more closely related to describe_instances from ec2. If we pass the instance_id it will jsut return the system for that instance id, in a *list* | 14:11 |
| RoAkSoAx | fwereade: or return a list of systems if instance_id not specified | 14:11 |
| fwereade | RoAkSoAx: I saw that, I'll probably change it to take (self, *instance_ids) to match more closely | 14:12 |
| fwereade | RoAkSoAx: I'm a little unsure about whether it's directly analogous though | 14:12 |
| RoAkSoAx | fwereade: note that I did this because *describe_instance* is used in other places and it doesn't assume that is it returns list, but rather just the info of a system | 14:12 |
| fwereade | RoAkSoAx: yep, that's cool | 14:12 |
| fwereade | RoAkSoAx: I'm just a little uncertain about the differences between what that returns and ec2 returns | 14:13 |
| RoAkSoAx | fwereade: but the reason why I did it is because we require to either return the info of an specified system, or the info of all the systems | 14:13 |
| RoAkSoAx | fwereade: yes, that's also what I want to discuss | 14:13 |
| fwereade | RoAkSoAx: it may be one of hose fundamental differences | 14:13 |
| RoAkSoAx | fwereade: indeed. so looking at iterate.py if you notice there's a fixme in line 120 of the diff I sent | 14:14 |
| RoAkSoAx | fwereade: in nthe commented part we are handling stuff such as "instance.dns_name" (line 128), while the way the systems are returned from cobbler, we cannot use it like that but rather something like "instance["name"]" | 14:15 |
| fwereade | RoAkSoAx: but it might be worth filtering on available mgmt_classes | 14:15 |
| fwereade | RoAkSoAx: I think those classes are expecting to work with Machine instances rather than system names | 14:15 |
| fwereade | RoAkSoAx: oops misunderstood | 14:16 |
| fwereade | RoAkSoAx: my internal definition of "describe_system" was "get everything you know", rather than "give me an identifier" | 14:16 |
| RoAkSoAx | fwereade: which I believe is the right thing to do for describe_systems. My only concern is why on ec2 it uses stuff such asnstance.dns_name or instance.instance_state in that particular function | 14:18 |
| fwereade | RoAkSoAx: just because that's what we get back from txaws | 14:18 |
| RoAkSoAx | fwereade: cause in our case, we would have to use instance["what-ever-field-on-dictionary"] | 14:18 |
| RoAkSoAx | fwereade: ah ok, so that answers my questions then | 14:18 |
| fwereade | RoAkSoAx: I feel that comes under the category of "acceptable difference" | 14:18 |
| fwereade | RoAkSoAx: cool | 14:19 |
| RoAkSoAx | fwereade: indeed. | 14:19 |
| RoAkSoAx | fwereade: one more thing. in cobbler.py lines such as: info = yield self._call("get_system", (name,)) | 14:20 |
| RoAkSoAx | fwereade: that call get_systems calls what? | 14:20 |
| fwereade | RoAkSoAx: sorry, can't parse | 14:20 |
| fwereade | RoAkSoAx: best guess, it calls the "get_system" cobbler api function, which returns the big dict | 14:21 |
| fwereade | RoAkSoAx: which "get_systems" helpfully gives us just a list of names ;/ | 14:21 |
| RoAkSoAx | fwereade: it gives us the list of systems with all its information | 14:21 |
| RoAkSoAx | fwereade: without filtering management classes | 14:22 |
| fwereade | RoAkSoAx: the singular version gives us loads of information | 14:22 |
| fwereade | RoAkSoAx: I'm pretty sure the plural version just gives us a listof names | 14:22 |
| RoAkSoAx | fwereade: no, both return the system(s) with all the information | 14:22 |
| fwereade | RoAkSoAx: ...I'll have to check that, I'm sure I was getting different results | 14:23 |
| RoAkSoAx | fwereade: ok | 14:24 |
| RoAkSoAx | fwereade: ok so, ltes imagine it returns a list of all systems without filtering management-classes | 14:24 |
| fwereade | RoAkSoAx: ok | 14:25 |
| fwereade | RoAkSoAx: just checked, you're perfectly right | 14:26 |
| * fwereade peers suspiciously at reality | 14:27 | |
| RoAkSoAx | fwereade: heheh :) anyways, what do you think we should do | 14:27 |
| RoAkSoAx | fwereade: 1. describe only the system filtering by management classes or 2. obtain absolutely all the systems and only filter them in _filter_provider_machines on iterate.py | 14:28 |
| fwereade | RoAkSoAx: to match ec2, it makes sense to filter so we only get acquired systems | 14:29 |
| fwereade | RoAkSoAx: and do that via find_system perhaps? | 14:29 |
| RoAkSoAx | fwereade: there's a way to return only the only the set of systems we want | 14:30 |
| RoAkSoAx | let me look into that first | 14:30 |
| RoAkSoAx | fwereade: but yes that's what I was thinking too | 14:30 |
| fwereade | RoAkSoAx: I changed some get_systems-and-itrate code to use find_system a while ago | 14:30 |
| RoAkSoAx | fwereade: anyways, I guess we are on the same page now, I'll finish this stuff and fw it to you for review/upload/tests or whatever you need to do to get it merged ;) | 14:31 |
| fwereade | RoAkSoAx: the troble is I can imagine cases where either has pathologically bad performance | 14:31 |
| fwereade | RoAkSoAx: sounds good :) | 14:31 |
| fwereade | RoAkSoAx: btw, I just pushed the latest set of updates to shadow-trunk | 14:32 |
| RoAkSoAx | fwereade: cool, will pull now ;) | 14:34 |
| RoAkSoAx | fwereade: but it looks like by friday we would have shadow-trunk up and running perfectly in preparation for the sprint ;) | 14:34 |
| fwereade | RoAkSoAx: fingers crossed :) | 14:35 |
| hazmat | hmm.. i think i've hit a zk binding bug | 14:47 |
| niemeyer | Uh oh | 14:52 |
| robbiew | http://www.sadtrombone.com | 14:59 |
| hazmat | the version doesn't increment publicly on acls | 15:20 |
| hazmat | working hypothesis set_acl doesn't seem to modify version | 15:21 |
| niemeyer | hazmat: I was kind of expecting this | 15:27 |
| niemeyer | hazmat: I wouldn't expect watches to fires with an acl change | 15:28 |
| niemeyer | s/fires/fire | 15:28 |
| === otubo is now known as otubo[AFK] | ||
| hazmat | niemeyer, makes sense, just not what i had done with the acl node modifications with a version retry loop, i guess there isn't anything to do with concurrent mods here. interesingly it does the right things for errors here, as using the same current version for multiple set_acls gives a badversionerror | 15:31 |
| niemeyer | hazmat: That sounds suspect | 15:32 |
| niemeyer | hazmat: It'd mean a node can only have its acl changed once | 15:32 |
| hazmat | niemeyer, per version | 15:32 |
| niemeyer | hazmat: Yes.. | 15:33 |
| hazmat | hmm | 15:33 |
| hazmat | nevermind, i'm still missing the bug somewhere | 15:33 |
| hazmat | i'm getting badversionerrors out of the acl modification code, even though i'm definitely passing in a current version | 15:34 |
| === daker is now known as daker_ | ||
| hazmat | niemeyer, aha.. that is the bug.. but only if version == 0 | 15:35 |
| RoAkSoAx | fwereade: ping | 15:35 |
| fwereade | RoAkSoAx: pong | 15:35 |
| niemeyer | hazmat: Well, it probably expects the current version to be provided | 15:35 |
| niemeyer | hazmat: But it won't update the version | 15:35 |
| niemeyer | hazmat: So you can set multiple times | 15:35 |
| niemeyer | hazmat: Is that right? | 15:35 |
| hazmat | niemeyer, the current version is being passed in all cases, if node version > 1, works fine, you can setacl multiples in a version, unless the node version == 0, ie the intial node content. | 15:36 |
| hazmat | then it raises badversionexc | 15:36 |
| RoAkSoAx | fwereade: I was looking at the connect.py from ec2, and I was wondering that the SSHClient stuff might explain why when obtaining the data for cloud-init for any deployed systems, it checked for the keys | 15:37 |
| RoAkSoAx | fwereade: were you able to look into that further? | 15:37 |
| niemeyer | hazmat: Interesting.. | 15:38 |
| hazmat | RoAkSoAx, i'm not familiar with the orchestra integration, but if cloud-init is being processed correctly, ensemble should already be passing in the keys for sshclient to work correctly | 15:38 |
| niemeyer | hazmat: Sounds like a bug indeed | 15:38 |
| fwereade | RoAkSoAx: I'm afraid I never did | 15:38 |
| RoAkSoAx | hazmat: right, the problem we had was that when I deployed, the zookeeper machine, checked to see if it had public ssh keys in the zookeeper, and we werent able to identify why but now that you are saying that the client machine should pass the keys to the zookeeper, that would make sense and should work | 15:39 |
| niemeyer | By the way, I'm working on the Formula Repository spec! | 15:41 |
| niemeyer | It took just an year to start this.. I guess I'll drink something tonight to celebrate | 15:42 |
| fwereade | well begun is best begun, and best begun is nearly finished :P | 15:44 |
| robbiew | m_3: what's your shirt size..3X or 2X :) | 15:48 |
| hazmat | niemeyer, actually it looks like you can't do multiple sets in a single version, you need to increment the version beyond what any of the node apis say the current version is for a subsequent set to work against, http://pastebin.ubuntu.com/658008/ | 15:49 |
| hazmat | regardless of the value of version | 15:49 |
| niemeyer | hazmat: This test doesn't give away much in terms of what's actual behavior (vs. what expected) | 15:51 |
| hazmat | RoAkSoAx, it happens different depending on if its the bootstrap node or seeding zk for the provisioning agent | 15:51 |
| hazmat | RoAkSoAx, for the bootstrap node the client key comes from cloud-init, for the provisioning agent, on the initial deploy the ssh keys are transported along with the materialized environment config to zk | 15:52 |
| hazmat | er. ssh pub key that is | 15:52 |
| hazmat | niemeyer, the failure catches are the ones setting the acl multiple times, i caught to verify with multiple version numbers, its simpler without the additional/redundant check | 15:54 |
| niemeyer | # Now i can do multiple setacls against the same version | 15:56 |
| niemeyer | # Fail if set multiple in same version | 15:56 |
| niemeyer | hazmat: The two sentences disagree.. | 15:56 |
| hazmat | niemeyer, yeah.. its rough.. the principals should be different as well | 15:56 |
| niemeyer | hazmat: So it fails every time? | 15:56 |
| niemeyer | hazmat: When setting multiple? | 15:56 |
| hazmat | niemeyer, yes, using setacl multiple times against the same version fails, and the publicly available node version doesn't change with setacl | 15:57 |
| niemeyer | hazmat: Would be worth understanding the background about this | 15:58 |
| niemeyer | hazmat: It feels like a very awkward behavoir | 15:58 |
| niemeyer | hazmat: It must be keeping track of the version in which ACLs are being set, and preventing following changes | 15:58 |
| niemeyer | hazmat: Which feels like additional work that would have to be explicitly done, rather than an oversight | 15:59 |
| hazmat | niemeyer, i see now.. there is another version number tracking all node changes | 15:59 |
| hazmat | {'pzxid': 3L, 'ctime': 1312387130343L, 'aversion': 2, 'mzxid': 6L, 'numChildren': 0, 'ephemeralOwner': 0L, 'version': 1, 'dataLength': 7, 'mtime': 1312387130408L, 'cve\ | 15:59 |
| hazmat | rsion': 0, 'czxid': 3L} | 15:59 |
| hazmat | aversion has the right version mod to use | 15:59 |
| hazmat | tracked separately from content to not effecting change watches | 16:00 |
| niemeyer | hazmat: Aha, phew | 16:02 |
| m_3 | robbiew: better go 3x if you're doing t-shirts | 16:02 |
| robbiew | m_3: ack | 16:02 |
| m_3 | robbiew: thanks! | 16:02 |
| fwereade | niemeyer: would you object to my making the machine_data/format_cloud_init-args change in a separate branch? I think it's going to add a bit too much noise to cobbler-launch-machine, but having it in a new branch would be a good opportunity to replace the machine_data bag that we all agree is suboptimal | 16:11 |
| === otubo[AFK] is now known as otubo | ||
| fwereade | need to be off, I'm afraid, see you all tomorrow | 16:31 |
| fwereade | reviews of my active mps always welcome ;) | 16:31 |
| _mup_ | ensemble/states-with-principals r304 committed by kapil.thangavelu@canonical.com | 16:43 |
| _mup_ | refactor security test integration, additional encapsulation of security convience apis into a domain node adapter. | 16:43 |
| _mup_ | ensemble/states-with-principals r305 committed by kapil.thangavelu@canonical.com | 16:44 |
| _mup_ | machine state creation security integration using the domain node adapter | 16:44 |
| fwereade | hey... was there a meeting at which I should have been just now? | 17:39 |
| RoAkSoAx | fwereade: late-command generation is broken i think | 17:42 |
| RoAkSoAx | fwereade: it fails to execute during installation | 17:42 |
| fwereade | RoAkSoAx: curses: since when? I appear to have totally broken something here, but I think I've somehow screwed up a version of a dependency | 17:43 |
| RoAkSoAx | fwereade: since right now... yesterday I was working with an old zookeeper I had running cause i couldn't install from mini iso for some reason | 17:44 |
| RoAkSoAx | fwereade: but today installation works, but late-command execution fails | 17:44 |
| * fwereade looks crestfallen | 17:45 | |
| fwereade | RoAkSoAx: I don't suppose you have a working ks_meta lying around on an old machine you can diff against? | 17:45 |
| fwereade | an old VM, from yesterday or something, I mean | 17:46 |
| RoAkSoAx | fwereade: i don | 17:46 |
| RoAkSoAx | fwereade: i don't | 17:46 |
| RoAkSoAx | unfortunately | 17:46 |
| RoAkSoAx | fwereade: ok found the error :P | 17:46 |
| niemeyer | fwereade: re. your previous question | 17:46 |
| niemeyer | fwereade: I feel half hearted about it.. | 17:46 |
| niemeyer | fwereade: :) | 17:47 |
| fwereade | RoAkSoAx: cool :) what did I do? | 17:47 |
| RoAkSoAx | fwereade: seems to be something wrong with _KSMETA_LATE_COMMAND_TEMPLATE formatting | 17:47 |
| RoAkSoAx | fwereade: I did this: _KSMETA_LATE_COMMAND_TEMPLATE = ("in-target sh -c 'f=$1; shift; echo $0 | base64 --decode | gunzip > $f && chmod u+x $f && $f $*' %s /root/late-command") and it works | 17:47 |
| RoAkSoAx | as it should | 17:47 |
| niemeyer | fwereade: The branch had quite a few points that made it look suboptimal for merging | 17:47 |
| fwereade | the launch-machine one? | 17:48 |
| niemeyer | fwereade: If you feel it's in a good state, I'll be happy to review | 17:48 |
| fwereade | niemeyer: sorry, which branch are you talking about? | 17:48 |
| niemeyer | fwereade: It's about your question: | 17:48 |
| niemeyer | <fwereade> niemeyer: would you object to my making the machine_data/format_cloud_init-args change in a separate branch | 17:48 |
| RoAkSoAx | fwereade: but now cloud-init is failing!! yay!! | 17:48 |
| fwereade | niemeyer: cobbler-launch-machine is still definitely WIP | 17:49 |
| fwereade | RoAkSoAx: yay! progress! | 17:49 |
| niemeyer | fwereade: Ok.. so keep pushing | 17:49 |
| fwereade | niemeyer: but I feel it's a little heavy already, and I thought it might be sensible to keep the machine_data/cloud_init changes to their own branch | 17:50 |
| niemeyer | fwereade: My impression of the branch on the review was that it needed fixing.. when you feel it's fixed, please push for review again, and mention what's still open or not, and we can take a decision | 17:50 |
| fwereade | niemeyer: ok, sounds good. thank you :) | 17:50 |
| niemeyer | fwereade: No worries | 17:50 |
| RoAkSoAx | fwereade: yes seems to be the formatting of _KSMETA_LATE_COMMAND_TEMPLATE | 17:50 |
| fwereade | RoAkSoAx: excellent (well, you know what I mean ;)) | 17:51 |
| RoAkSoAx | fwereade: apply this patch please: http://paste.ubuntu.com/658080/ | 17:55 |
| fwereade | RoAkSoAx: thank you, that looks eminently sensible | 17:59 |
| niemeyer | RoAkSoAx: Huh | 17:59 |
| RoAkSoAx | niemeyer: ? | 17:59 |
| niemeyer | RoAkSoAx: Trying to understand why we're doing all of that | 17:59 |
| fwereade | RoAkSoAx: safely saved to be applied tomorrow, I'm afraid; I have to dash again for now (*might* make it back later) | 18:00 |
| RoAkSoAx | fwereade: aif you could pply it to shadow-trunk in the meantime would be great | 18:00 |
| niemeyer | RoAkSoAx: This feels like a very complex way to say echo %s | base64 --decode | sh - | 18:00 |
| RoAkSoAx | niemeyer: that's what be were doing before, but fwereade missed those bits :) | 18:00 |
| niemeyer | I won't complain too much, but I'd probably shrink it down a bit | 18:02 |
| RoAkSoAx | niemeyer: yes, but as discussed in MIA, i preferred to keep it cause of the creation of late-command for debugging purposes | 18:05 |
| RoAkSoAx | niemeyer: as was also recommended by smoser | 18:05 |
| smoser | niemeyer, i dont think that it being complex is necessarily a good reason to not like it. | 18:09 |
| smoser | your suggested replacement needs a few changes to actually work. | 18:09 |
| smoser | base64 is not necessarily available outside target, you need 'in-target' somehwere. | 18:10 |
| smoser | the real benefit of doing it the way i have it is that it is not tied to the output of base64 being executed by 'sh' | 18:10 |
| smoser | also, it handles passing parameters to the command. | 18:11 |
| niemeyer | smoser: Being unnecessarily complex is the reason I don't like it.. | 18:11 |
| smoser | not unnecessarily complex to address those 2 features. | 18:11 |
| smoser | oh, and gzipped (yours would need gzip in the pipeline) | 18:12 |
| niemeyer | smoser: What are the features you'd like to see there? | 18:12 |
| smoser | gzip compression, ability to see the script on disk after you've used it (debugging), ability to pass arguments to the script [correctly quoted], ability to execute non 'sh' content without changing that ks macro | 18:13 |
| niemeyer | smoser: in-target /bin/sh -c "echo %s | base64 --decode | gunzip > $1 && chmod +x $1 && $1" /root/late-command | 18:15 |
| niemeyer | smoser: I'd drop gzip.. but that's another topic | 18:15 |
| smoser | i dont know. i'd have ot play with it. | 18:17 |
| smoser | you cant use single double quotes reliably | 18:18 |
| smoser | do to parsing of ks_args | 18:18 |
| smoser | but i admit that that is fuzzy in my recollection | 18:18 |
| smoser | the other hting that ish't present in yours is the ability to pass arguments to the command you're executing | 18:18 |
| smoser | (which could easiliy be other ks_args) | 18:18 |
| smoser | which is what the shift; and $* accomplish | 18:18 |
| smoser | but i think this conversation is all very bikeshed. you have something that works, tested as works, and you're just trying to change it so you can spend more time testing. | 18:19 |
| smoser | comparing what yo uare suggesting and what i have, the only difference i see is: | 18:22 |
| smoser | * use of double quotes (which i think is causing the problem) | 18:22 |
| smoser | * use of a variable name | 18:24 |
| smoser | anyway | 18:24 |
| _mup_ | ensemble/states-with-principals r306 committed by kapil.thangavelu@canonical.com | 18:43 |
| _mup_ | enable group members to be added via the domain security object to allow for disabling security to increase test speed. | 18:43 |
| smoser | oh, niemeyer and yours above has a bug. | 18:44 |
| smoser | you need to use '$0' in that case, as '/root/late-command' is the 0th argument, not the first. | 18:44 |
| niemeyer | smoser: That's because you're using shift within a one-liner | 18:44 |
| niemeyer | smoser: Which is strange | 18:44 |
| smoser | i dont think so. | 18:45 |
| smoser | but... | 18:45 |
| smoser | but your $1 is wrong | 18:45 |
| niemeyer | smoser: Yes.. that's what shift does | 18:45 |
| niemeyer | $0 is the executable name by default | 18:45 |
| niemeyer | % /bin/sh -c "echo \$0" | 18:45 |
| niemeyer | /bin/sh | 18:45 |
| smoser | $ sh -c 'echo 0=$0; echo 1=$1' "hi mom" "arg1" | 18:45 |
| smoser | 0=hi mom | 18:45 |
| smoser | 1=arg1 | 18:45 |
| niemeyer | smoser: Crazy.. you're right.. /bin/sh changes depending on args | 18:46 |
| smoser | of course i'm righ | 18:47 |
| smoser | :) | 18:47 |
| smoser | it is confusing. i agree. | 18:47 |
| niemeyer | smoser++ | 18:49 |
| niemeyer | ;) | 18:49 |
| niemeyer | smoser: Still, you see the point? It feels like there's more being done than necessary | 18:50 |
| niemeyer | smoser: That said, I won't complain too much.. this is minor, and if you feel strong about a particular approach, let's take it | 18:51 |
| smoser | so.. the thing i like about the way i did it is that you dont muck with the internals of the 'sh' command. | 18:52 |
| smoser | you're just modifying what arguments you pass to it | 18:52 |
| smoser | (ie, the '%s' is outside the single ticks) | 18:52 |
| smoser | and you can pass additional arguments also and they'll get passed onto the content of the script. | 18:52 |
| smoser | but either way can be made to work. | 18:52 |
| niemeyer | smoser: Yeah, it's cool | 18:53 |
| niemeyer | smoser: We can keep as it is if you're more comfortable that way | 18:53 |
| smoser | well if it works i'd say keep it. | 18:54 |
| smoser | if it breaks, fix it | 18:54 |
| smoser | :) | 18:54 |
| niemeyer | smoser: From the messages I read above, it wasn't working either way | 19:26 |
| niemeyer | smoser: Which is why I suggested a simpler approach | 19:27 |
| smoser | RoAkSoAx said it works for him | 19:28 |
| RoAkSoAx | smoser: niemeyer it does work for me | 19:31 |
| RoAkSoAx | niemeyer: the problem is fixed, The command was incorrectly copied from the bootstrap-cobbler branch to the shadow-trunk branch we are wroking on top of | 19:31 |
| niemeyer | smoser: ^ | 19:31 |
| niemeyer | All good.. | 19:31 |
| === otubo is now known as otubo[AFK] | ||
| === otubo[AFK] is now known as otubo | ||
| hazmat | sigh.. getting security integrated into the tests is proving painful | 21:33 |
| * hazmat wonders if all of the core dev team have ssds | 21:48 | |
| hazmat | yeah.. several of the status tests time out on a rotating hd, definitely don't on ssd | 21:52 |
| hazmat | hmm | 21:52 |
| hazmat | or maybe this is more integration fun | 21:52 |
| * robbiew prepares PO for ssds | 21:52 | |
| robbiew | :P | 21:52 |
| hazmat | ftw ;-) | 21:52 |
| robbiew | hazmat: you have an x220, right? | 21:53 |
| hazmat | robbiew, i do.. haven't picked up a 7mm ssd yet or the msata ssd.. been putting my piggybank towards a nas ;-).. the x220 support's been somewhat problematic atm, kernel panic on sleep.. haven't really dug into it much | 21:54 |
| robbiew | yeah....I'm running 11.10 and the power usage is shit | 21:55 |
| * robbiew goes to poke manjo...he's our "inside guy" with Lenovo ;) | 21:55 | |
| hazmat | outside of that.. its really nice hardware, the screen is great.. my battery life is decent (sadly with a nine cell).. i'm hoping to pickup the battery slice if i have to do any long trips | 21:55 |
| robbiew | yeah...I got the touchscreen version...not bad...but the utouch stuff doesn't work | 21:56 |
| robbiew | I'm going to pester the appropriate folks at next UDS though ;) | 21:56 |
| === otubo is now known as otubo[AFK] | ||
| niemeyer | I'm starting to feel happier about the namespaces concept in the repo spec | 22:06 |
| niemeyer | I'll try to push this for an early review sometime tomorrow | 22:09 |
| niemeyer | I'm stepping out for the night, I think :) | 22:20 |
| niemeyer | Have a good time all | 22:20 |
| robbiew | look out! | 22:26 |
| robbiew | lol | 22:26 |
| _mup_ | ensemble/states-with-principals r307 committed by kapil.thangavelu@canonical.com | 23:35 |
| _mup_ | encapsulate removal of group members into security adapter, utilize decorator for tests that need security (when the default is off) | 23:35 |
| hazmat | i wish profiling where more useful with twisted | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!