| jimbaker | m_3, is the corresponding branch actually merged in yet? it's not marked as being so in bug 828152 | 00:04 |
|---|---|---|
| _mup_ | Bug #828152: default formula config values not available to hooks <Ensemble:Fix Released by bcsaller> < https://launchpad.net/bugs/828152 > | 00:04 |
| jimbaker | bcsaller, ^^^ | 00:05 |
| bcsaller | jimbaker: yeah, missed the first comment I see | 00:05 |
| jimbaker | bcsaller, thanks for merging it in | 00:33 |
| jimbaker | m_3, enjoy! | 00:33 |
| bcsaller | jimbaker, m_3: sorry, forgot to go back to it. That was important as far as the feature is concerned too | 00:34 |
| jimbaker | bcsaller, np, just unfortunate it had been hiding in plain sight in the kanban | 00:36 |
| bcsaller | jimbaker: I think what happened was I committed with --fixes (trying that out) and it got the status out of sync | 00:37 |
| jimbaker | bcsaller, you mean --fixes against something besides trunk? | 00:38 |
| jimbaker | (i use --fixes all the time) | 00:38 |
| jimbaker | looking at the log not too closely, apparently i'm the only one who does so ;) | 00:39 |
| jimbaker | or at least consistently. i did see usage by hazmat at r298 | 00:40 |
| jimbaker | bcsaller, i don't --fixes actually changes anything in lp however. i always have to go and still mark it as "fix released" | 00:42 |
| bcsaller | I though it set it to 'fix committed', not sure | 00:43 |
| jimbaker | again, that's something one would set manually as i understand it | 00:44 |
| jimbaker | but at least the fix is now in! | 00:44 |
| hazmat | jimbaker, i tried it but it had an effect | 00:45 |
| hazmat | odd one that is | 00:45 |
| hazmat | it would link trunk to the bug report | 00:45 |
| jimbaker | hazmat, i believe it simply and only adds the metadata to the log | 00:46 |
| jimbaker | so it's redundant with respect to [f=XXX], but possibly useful once we always use it | 00:47 |
| hazmat | jimbaker, i've seen it happen more than once | 00:47 |
| hazmat | jimbaker, take a look at one of your merge proposals https://bugs.launchpad.net/ensemble/+bug/825398 | 00:48 |
| _mup_ | Bug #825398: Store Ensemble version number in topology node and verify ops <Ensemble:Fix Released by jimbaker> < https://launchpad.net/bugs/825398 > | 00:48 |
| hazmat | see how's it linked to trunk | 00:48 |
| hazmat | and linked to it on the kanban | 00:48 |
| hazmat | i find that an anti-feature | 00:48 |
| hazmat | i can see its use when we use fix-committed and have actual releases though | 00:48 |
| hazmat | but for our current usage modes, its more interesting to me, to see the merge proposal branch linked | 00:49 |
| hazmat | so i stopped using --fixes | 00:49 |
| jimbaker | hazmat, ok, so it linked trunk into the bug, changing the kanban to report lp:ensemble for the fixing branch? | 00:50 |
| hazmat | jimbaker, its the metadata gets processed by launchpad | 00:50 |
| jimbaker | yes, that would be anti-feature | 00:50 |
| hazmat | once the commit that has --fixes lands in trunk, it updates the branch to link to the bug | 00:50 |
| jimbaker | so possibly more useful in a more complex scenario because we can see where the fix is | 00:51 |
| hazmat | jimbaker, its a different use case it solves, we typically want to see which branch the bug fix/feature impl landed in, and the merge proposal discussion | 00:52 |
| hazmat | the --fixes use case is to show someone looking at the bug the current location of the fix | 00:52 |
| hazmat | we already have fix committed bug status which would denote that its on trunk, and fixed release to show its been released.. on bug status | 00:53 |
| jimbaker | hazmat, yes, it makes sense now | 00:53 |
| hazmat | jimbaker, i'd suggest we avoid using --fixes, it doesn't match our use case | 00:53 |
| jimbaker | it would be sort of nice if the kanban showed the originating branch | 00:53 |
| jimbaker | but in the meantime, we can just stop using --fixes | 00:54 |
| hazmat | bcsaller, not sure why i was so dense about cloud init, looking at the updates its very clear why not. | 01:03 |
| bcsaller | hazmat: so you did get a chance to see it, let me know if you need changes. In the meantime I am improving the script | 01:04 |
| hazmat | i suppose either would have worked.. but this seems cleaner | 01:04 |
| bcsaller | hazmat: also it currently doesn't arrange for the agent to run but I expect that will be triggered again by data in /etc | 01:04 |
| hazmat | bcsaller, looks good, a couple over 80 lines | 01:05 |
| hazmat | bcsaller, what's /etc/ensemble supposed to be again? | 01:05 |
| bcsaller | hazmat: its the variables that get sourced by the script to control its behavior. Cloud init can write stuff there as well and then resuse the same scripts | 01:05 |
| bcsaller | maybe... I think, we'll see, thats what I'm going for anyway | 01:06 |
| hazmat | make sense though, we can drop some useful immutable conf there like agent ids | 01:07 |
| hazmat | not clear if we can source the file in an upstart job though | 01:10 |
| hazmat | ah. the script section is an entire block | 01:11 |
| hazmat | sounds good | 01:11 |
| _mup_ | ensemble/lxc-lib-merge r324 committed by kapil.thangavelu@canonical.com | 01:18 |
| _mup_ | local provider skeleton and utils for setting up network and zk | 01:18 |
| _mup_ | ensemble/local-ubuntu-provider r324 committed by kapil.thangavelu@canonical.com | 01:20 |
| _mup_ | local provider skeleton and utils for setting up network and zk | 01:20 |
| _mup_ | ensemble/lxc-lib-merge r324 committed by kapil.thangavelu@canonical.com | 01:21 |
| _mup_ | merge lxc-lib | 01:21 |
| niemeyer | Man.. long day | 01:22 |
| niemeyer | Time to sit in the couch and not move for a while | 01:22 |
| niemeyer | Have good EOD everyone | 01:22 |
| hazmat | niemeyer, bcsaller do we want to support multiple lxc environments simultatenously for oneiric? | 01:25 |
| hazmat | niemeyer, cheers | 01:25 |
| jimbaker | niemeyer, take care | 01:25 |
| hazmat | i was thinking it would be better to do it with chroots, but i'm trying to keep support for it, but if we wanted to do it, it means namespacing things with the env name, which means the env name in the configuration.yaml becomes immutable after use | 01:26 |
| bcsaller | hazmat: like many different network bridges at the same time and all that... it shouldn't be that much worse I think, but it shouldn't be that much needed (I hope) | 01:32 |
| hazmat | bcsaller, indeed, although its not absolutely clear we really need multiple bridges, i structured it that way for now | 02:05 |
| bcsaller | and the interface to that I gave you seemed ok? | 02:07 |
| adam_g | cool. ensemble on oneiric should be bootstrapable again. hail smoser. | 02:27 |
| smoser | yeah, with 20110822.2 | 02:35 |
| smoser | adam_g, is anyone testing/using canonistack? | 02:36 |
| adam_g | smoser: testing what? ensemble? cloud-init? | 02:36 |
| adam_g | i haven't touched canonistack, honestly, but i believe hazmat had gotten it working | 02:36 |
| adam_g | (ensemble bootstrap) | 02:36 |
| hazmat | smoser, i've done a bootstrap and deploy on canonistack | 02:37 |
| hazmat | smoser, it needs some branches though | 02:37 |
| hazmat | till its landed on trunk, instructions for the brave.. for ensemble+openstack.. http://pastebin.ubuntu.com/673083/ | 02:38 |
| === otubo is now known as otubo[AFK] | ||
| === otubo[AFK] is now known as otubo | ||
| === daker_ is now known as daker | ||
| RoAkSoAx | fwereade: howdy!! | 13:32 |
| fwereade | RoAkSoAx: heyhey | 13:33 |
| fwereade | RoAkSoAx: how's it going? | 13:33 |
| hazmat | g'morning folks | 13:38 |
| niemeyer | Hey folks | 13:39 |
| niemeyer | How's life? | 13:40 |
| niemeyer | hazmat: Shaken up? | 13:40 |
| * niemeyer hides | 13:40 | |
| hazmat | niemeyer, no stirred not shaken ;-) | 13:40 |
| hazmat | there was a funny picture on twitter.. 'damage from the earthquake' and showed a some plastic chairs on a lawn, with one fallen down. | 13:41 |
| RoAkSoAx | fwereade: good good | 13:42 |
| RoAkSoAx | fwereade: did you update the cobbler-complete branch with the latest fixes? | 13:42 |
| fwereade | RoAkSoAx: let me do that for you now | 13:43 |
| fwereade | RoAkSoAx: blech, conflicts, might take a few minutes | 13:47 |
| niemeyer | hazmat: I was quite surprised with the lack major damage with a 5.8 | 13:48 |
| niemeyer | hazmat: That region doesn't sit on top of a failure, does it? | 13:48 |
| hazmat | niemeyer, no its actually a very inert area, its in the middle of a plate, not an edge | 13:49 |
| RoAkSoAx | fwereade: hehe ok no worries | 13:50 |
| niemeyer | hazmat: Creepy :( | 13:54 |
| hazmat | niemeyer, so i'm trying to figure out if we want to support multiple environments running simulatenously in the local dev story | 13:55 |
| hazmat | and if so should they be isolated (separate network bridge per env) or be able to talk to each other.. at this point i'm thinking yes to the former, and no to the latter. ideally we'd be using a single zk with a chroot, but for now it could work with multiple zks | 13:56 |
| hazmat | the real issue is that it would end up codifying the env name into persistent datastructures (unit dirs for example) that would mean the environment name in the ensemble yaml config would become immutable | 13:57 |
| niemeyer | hazmat: +1 on yes to the former and no to the latter | 13:58 |
| hazmat | niemeyer, so single network bridge for all local envs? | 13:59 |
| niemeyer | hazmat: Uh.. that's what you said above :) | 13:59 |
| hazmat | i can't think of any good reason to restrict it for the local case ;-) | 13:59 |
| hazmat | niemeyer, indeed, but i added an 'or' clause which made the whole thing ambigious | 13:59 |
| hazmat | to a simple yes/no | 13:59 |
| niemeyer | hazmat: Ok.. I misunderstood then | 13:59 |
| niemeyer | hazmat: I think they should be isolated.. there's no good reason to make them communicate with each other, and isolating at this point is just organizational | 14:00 |
| * robbiew is getting loads of DevOpsolution shirt requests | 14:52 | |
| jimbaker | fwereade, thanks for the headsup on the refactoring conflicts | 15:07 |
| _mup_ | Bug #833064 was filed: orchestra has no firewalls <Ensemble:New> < https://launchpad.net/bugs/833064 > | 15:13 |
| === Hussain is now known as Guest58634 | ||
| niemeyer | fwereade: Btw, I know the review queue is a bit on the upper side right now.. I'll take care of it tomorrow, if that's ok | 15:37 |
| fwereade | niemeyer: no worries | 15:38 |
| niemeyer | fwereade: I'm trying to put some focused work on the store, or we won't have it | 15:38 |
| fwereade | niemeyer: there are at least a couple of little ones, and it'll be a little while before it grows again | 15:38 |
| _mup_ | Bug #833113 was filed: test should support a JUnit XML reporter <Ensemble:New> < https://launchpad.net/bugs/833113 > | 15:57 |
| hazmat | niemeyer, re the multi-environment local support, so immutability of env names in config.yaml is a consequence, which i'm not sure about.. i'd rather avoid it, but i don't see any good solutions outside of some additional mapping/identifier for environments.. the problem arises in networks/disk structures referencing the environment name as part of qualified unit name resolution.. multi-env on one machine breaks the unit id is unique which we curren | 16:01 |
| hazmat | tly use for unit state on disk. | 16:01 |
| _mup_ | Bug #833119 was filed: Deploy Jenkins with support for EC2 functional testing <Ensemble:New for jimbaker> < https://launchpad.net/bugs/833119 > | 16:01 |
| === daker is now known as daker_ | ||
| niemeyer | jimbaker: My message in the list is still unanswered.. that's really not how a distributed team works. | 16:02 |
| jimbaker | niemeyer, as i mentioned yesterday, i started working on this yesterday. please expect me to report on my findings shortly | 16:03 |
| niemeyer | jimbaker: That's not how a distributed team works.. | 16:03 |
| jimbaker | niemeyer, thanks for the clarification | 16:03 |
| niemeyer | jimbaker: Email is for communication | 16:03 |
| niemeyer | jimbaker: I've made a simple question to open a conversation | 16:04 |
| niemeyer | jimbaker: I didn't expect a whitepaper back | 16:04 |
| jimbaker | niemeyer, understood | 16:04 |
| niemeyer | jimbaker: XML report for Jenkins seems overblown.. let's start simple. 1 or 0 exit code is failure/success.. dump text output, and make available. | 16:05 |
| niemeyer | hazmat: Hmm | 16:07 |
| hazmat | bcsaller, afaics we're just using the standard lxc-ubuntu template now with lxc, and we don't need any upstream changes | 16:07 |
| hazmat | is that correct? | 16:07 |
| niemeyer | hazmat: It sounds fine to namespace according to env name | 16:07 |
| niemeyer | hazmat: Perhaps user name (or id) + env name, though | 16:07 |
| jimbaker | niemeyer, the xml output is quite simple (as seen in XmlTestRunner), and it has the advantage that this is what CI systems in general are looking for. the only issue here is enabling an appropriate plugin reporter that integrates with twisted trial | 16:07 |
| hazmat | niemeyer, i just worry about new users, who change an env name, which works fine for ec2, orchestra, but not local-lxc | 16:07 |
| niemeyer | jimbaker: I'll take your word for it.. I'd like to see this working this week still. | 16:08 |
| hazmat | niemeyer, good point re + user | 16:08 |
| niemeyer | jimbaker: Not in a month | 16:08 |
| jimbaker | niemeyer, cool, i understand the JDFI mandate | 16:08 |
| niemeyer | jimbaker: Not a JFDI, not a mandate.. we have a simple problem, requiring a simple solution | 16:08 |
| niemeyer | jimbaker: If you do it next month, we don't need it anymore | 16:08 |
| jimbaker | niemeyer, understood | 16:08 |
| bcsaller | hazmat: don't need, no, could still use, but its not a blocker | 16:11 |
| hazmat | bcsaller, awesome | 16:11 |
| niemeyer | Lunch time, biab | 16:11 |
| hazmat | fwereade, the cloud-init-class-replace branch mp depends on cloud-init-class-add branch but the latter is not in review? | 16:31 |
| hazmat | and without a merge proposal | 16:31 |
| fwereade | hazmat: explained in the -replace mp | 16:44 |
| hazmat | ah | 16:44 |
| fwereade | hazmat: I'm probably Doing It Wrong, but the -add is just to make life easier for the reviewers so you get a clear break between two reaosnably self-contained diffs | 16:44 |
| hazmat | fwereade, indeed the merge proposal explains it well, thanks | 16:45 |
| fwereade | hazmat: cool, cheers | 16:45 |
| fwereade | hazmat, btw, thank you very much for all the reviewing you've been doing | 17:01 |
| fwereade | and, everyone, see you tomorrow :) | 17:01 |
| hazmat | fwereade, np, the others where small and easy, have a good one | 17:02 |
| hazmat | bcsaller, what do you think of using link local addresses for connecting units to zk? | 17:42 |
| hazmat | localhost is shadowed, and ip addresses otherwise are subject to drift | 17:42 |
| hazmat | hmm | 17:42 |
| bcsaller | hazmat: I'd have to experiment to guess whats best there | 17:43 |
| hazmat | bcsaller, yeah.. i've been playing around, the question is having an immutable network reference, and ip addresses are subject to change and recycling | 17:44 |
| bcsaller | hazmat: it seems like dns would work for this though | 17:44 |
| hazmat | just not sure if link local addresses are stable and always present | 17:44 |
| hazmat | bcsaller, i | 17:44 |
| hazmat | hmm | 17:45 |
| bcsaller | it also doesn't seem like this is a problem we wouldn't have in other environments | 17:45 |
| bcsaller | or rather if this is an issue we already have it, no? | 17:45 |
| hazmat | bcsaller, dns works well from the host to the container, most of our communication is in reverse, how does the host past a network reference the container that's resolvable from the container | 17:46 |
| hazmat | ^to the | 17:46 |
| hazmat | interesting | 17:46 |
| hazmat | bcsaller, dns resolve on the host name from the container returns 127.0.1.1 | 17:46 |
| m_3 | libvirt creates a virbr0, assigns private (not link-local) addresses, runs dnsmasq for dhcp, and NATs through the host via iptables | 17:48 |
| hazmat | bcsaller, that works well | 17:49 |
| m_3 | that dnsmasq might resolve names... dunno | 17:49 |
| hazmat | m_3, that works well for host resolving containers, in this case the host (runnning zk) wants to pass an address to the contains they can connect to zk on | 17:50 |
| m_3 | right... the host is addressable(sp?) from the guests via that virbr0 interface (usually 192.168.122.1) | 17:52 |
| hazmat | m_3, at what address from the container ? | 17:53 |
| hazmat | m_3, it looks like 127.0.1.1 works.. although in truth that might be an effect from a desktop installation | 17:53 |
| m_3 | guests are dhcp-assigned via dnsmasq (running bound to the virbr0 interface of the host on 192.168.122.0/24) | 17:54 |
| m_3 | that's the 'default' setup | 17:54 |
| m_3 | dnsmasq is the crucial key for the libvirt networking | 17:56 |
| m_3 | (with iptables if you need external bridging... not sure if you do) | 17:56 |
| m_3 | dnsmasq is more moving parts, I understand... but don't know of a lighter way to do what you're trying to do | 17:57 |
| _mup_ | Bug #833248 was filed: Deploying formulas no longer works <Ensemble:New> < https://launchpad.net/bugs/833248 > | 17:58 |
| hazmat | m_3, i understand the bridge and the ip addresses, and resolving names onto the bridge, as well as what dnsmasq provides for outside world connectivity, but the question is specifically addressing the host machine from the container.. i think i've got a good solution just need to some verification, else i'll use hostname resolution | 18:00 |
| hazmat | ^to do | 18:00 |
| m_3 | cool, gotcha | 18:02 |
| m_3 | that'd be nice and lightweight | 18:02 |
| hazmat | i'm concerned that 127.0.1.1 is created as a consequence of installing a desktop package | 18:07 |
| hazmat | per http://qref.sourceforge.net/quick/ch-gateway.en.html section 10.4 | 18:07 |
| niemeyer | hazmat: Can you please have a look at #833248? | 18:09 |
| _mup_ | Bug #833248: Deploying formulas no longer works <Ensemble:New> < https://launchpad.net/bugs/833248 > | 18:09 |
| hazmat | niemeyer, woah.. yeah... i'm on it | 18:10 |
| niemeyer | hazmat: Thanks! | 18:10 |
| niemeyer | adam_g: Will be working again in a moment.. sorry about that | 18:10 |
| adam_g | niemeyer: thanx & np | 18:14 |
| hazmat | it looks like the s3 signature is wrong | 18:30 |
| * hazmat can't wait for functional tests | 18:37 | |
| SpamapS | https://ensemble.ubuntu.com/kanban/ .. no eureka? | 18:38 |
| hazmat | hmm.. the aws documentatoin is wrong | 18:44 |
| hazmat | someone is wrong on the internet ;-) | 18:44 |
| hazmat | niemeyer, i can revert back the machine-agent-uses-formula-url branch merge for now and trigger the ppa build, the s3 documentation i was using appears to be wrong, http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html ... i've copy and pasted the example code and it gets the same error | 18:49 |
| hazmat | i'm probably getting something wrong | 18:49 |
| niemeyer | hazmat: Have you checked the goamz implementation? | 18:50 |
| niemeyer | hazmat: It has integration tests against S3 itself, so it must be right | 18:50 |
| niemeyer | hazmat: Well.. I suppose txaws should be too | 18:50 |
| hazmat | niemeyer, they don't generate signing urls, they use additional headers afaicr | 18:51 |
| hazmat | ie. with Authorization: AWS XXX header | 18:52 |
| niemeyer | hazmat: Indeed | 18:52 |
| hazmat | comparing against boto | 18:53 |
| niemeyer | hazmat: Quite surprising | 18:53 |
| niemeyer | hazmat: The algorithm is very close to the normal one, though | 18:54 |
| hazmat | niemeyer, it is exactly the same just with additional quoting | 18:54 |
| niemeyer | hazmat: and the Expires | 18:55 |
| niemeyer | hazmat: Is it including the Expires as a query parameter? Also, are you sure the canonicalization is right? | 18:56 |
| niemeyer | hazmat: Would be worth taking another signer algorithm, and trying to pass it in a URL for testing purposes | 18:56 |
| hazmat | niemeyer, its using expires, i'm comparing against boto right now | 18:57 |
| hazmat | niemeyer, ah.. the bucket key also needs quoting | 18:58 |
| niemeyer | hazmat: Phew, cool | 18:59 |
| hazmat | hmm | 19:02 |
| === otubo is now known as otubo[AFK] | ||
| hazmat | niemeyer, bcsaller, jimbaker can i get a +1 on https://pastebin.canonical.com/51668/ | 19:48 |
| * niemeyer checks | 19:48 | |
| jimbaker | taking a look | 19:48 |
| hazmat | some reformatting, but the basic change is urllib.quote(path) | 19:49 |
| hazmat | s/basic/functional | 19:49 |
| niemeyer | hazmat: I think the strip may be dropped | 19:50 |
| niemeyer | hazmat: It looks good in principle.. I have no idea if the actual algorithm is right or not, though, so my review isn't really worth much in this case | 19:51 |
| niemeyer | hazmat: +1 with real interaction working | 19:51 |
| hazmat | niemeyer, yeah.. in progress on testing that | 19:51 |
| * hazmat gets some caffiene | 19:51 | |
| jimbaker | hazmat, looks reasonable, and strip is unnecessary - it's already padded with = | 19:53 |
| hazmat | ah.. that's why testing is odd | 20:03 |
| hazmat | the old formulas stick around | 20:03 |
| niemeyer | hazmat: Bump ensemble.state.topology.VERSION? | 20:04 |
| hazmat | niemeyer, in s3.. still digging through it, i'm not hitting pdbs and prints that i'd expect to | 20:04 |
| hazmat | i'm not concerned about zk compatibility yet | 20:05 |
| lynxman | hazmat: ping | 20:52 |
| susanb | hi. | 20:54 |
| susanb | have a quick question re: hadoop formula - where do I find it?? | 20:55 |
| hazmat | lynxman, pong | 20:56 |
| _mup_ | ensemble/trunk r327 committed by kapil.thangavelu@canonical.com | 20:58 |
| _mup_ | [trivial] fix for broken s3 signed url mechanism [r=niemeyer,jimbaker][f=833248] | 20:58 |
| _mup_ | The s3 bucket and key name paths needed to be quoted as well for the signed url signature. | 20:58 |
| _mup_ | This prevented formula deployment. | 20:58 |
| niemeyer | hazmat: Woohay! | 20:59 |
| hazmat | new ppa build requested | 20:59 |
| lynxman | hazmat: hey, I'm trying to deploy formulas with ensemble on Canonistack, just as a test to make sure that all is in place for our Ensemble + Openstack sprint next week | 21:00 |
| hazmat | jimbaker, looking forward to functional tests, there's also the corbertura plugin for coverage (which has a compatible xml report option) | 21:00 |
| lynxman | hazmat: unfortunately the problem reported by TREllis is still there, is there any update on this from your side? | 21:00 |
| hazmat | lynxman, i've got some branches that allowed me to deploy formulas successfully.. i should have the branches into review this week, but it might be next week b4 their merged, trying to focus on lxc atm, but i hadn't heard about the sprint.. the instructions for using the branches are at . http://pastebin.ubuntu.com/673083/ .. | 21:02 |
| hazmat | lynxman, is there any info on the ensemble+openstack sprint out there? | 21:03 |
| lynxman | hazmat: yeah I've done exactly that, it doesn't work :) | 21:03 |
| hazmat | lynxman, cool, so what's the problem? | 21:03 |
| lynxman | hazmat: This https://pastebin.canonical.com/51673/ | 21:04 |
| lynxman | hazmat: which is exactly the same problem that TREllis reported a couple days ago | 21:04 |
| lynxman | hazmat: the Sprint is about writing a white paper for deploying openstack and workloads over it using orchestra + ensemble | 21:05 |
| hazmat | lynxman, can you paste your redacted environments.yaml file? | 21:05 |
| lynxman | hazmat: so we use ensemble to deploy openstack then ensemble again to deploy workloads over that openstack :) | 21:05 |
| lynxman | sure | 21:05 |
| hazmat | lynxman, turtles all the way down, cover page of the white paper ;-) | 21:05 |
| lynxman | hazmat: lol | 21:05 |
| lynxman | hazmat: https://pastebin.canonical.com/51674/ | 21:06 |
| jimbaker | hazmat, i will definitely take a look at adding in corbertura after we get solid functional testing in place. right now just finalizing the jenkins setup, the junit xml stuff is working fine | 21:08 |
| hazmat | lynxman, hmm.. so i suspect the problem is not having the branches on your pythonpath on the admin side | 21:09 |
| hazmat | lynxman, you might need to set PYTHONPATH=$aws_branch_path:$ensemble_branch_path:$PYTHONPATH before running | 21:10 |
| lynxman | hazmat: aah I see, ye oldie pythonpath problem, I'll create a .pth for that, gimme just 2 mins :D | 21:10 |
| hazmat | lynxman, you can confirm by using.. $ python, >>> import txaws, >>> print txaws | 21:11 |
| hazmat | and verify its at the branch path | 21:11 |
| lynxman | hazmat: yeah lack of pythonpath https://pastebin.canonical.com/51675/ | 21:12 |
| lynxman | hazmat: will create the .pth and get back to you asap | 21:12 |
| hazmat | lynxman, virtualenv ftw | 21:13 |
| jimbaker | hazmat, of course when used with caution. but fine against trunk | 21:14 |
| lynxman | hazmat: haven't played much with virtualenv :) | 21:14 |
| lynxman | hazmat: been trying to for months, never got to it | 21:14 |
| * lynxman clearly needs 27 hour days | 21:14 | |
| jimbaker | lynxman, it can create quite inscrutable errors i have found | 21:14 |
| jimbaker | but usually it works well | 21:14 |
| hazmat | lynxman, if you find one, let me know ;-).. | 21:14 |
| lynxman | hazmat: oh I will, hehe | 21:15 |
| hazmat | jimbaker, the multiple directory branch model not working well with setup.py develop (stale directory pointers in easy-install.pth), is a little different than virtualenv issues, that would happen regardless of virtualenv. | 21:16 |
| lynxman | hazmat: actually I compiled the eggs and put them in the new path and it works well now, just a minor misconfig issue | 21:18 |
| lynxman | hazmat: you da man | 21:18 |
| hazmat | lynxman, awesome | 21:18 |
| * lynxman high fives hazmat | 21:18 | |
| * hazmat grabs some more caffiene | 21:18 | |
| jimbaker | hazmat, sure just more places for the problem to hide i think | 21:18 |
| hazmat | back to lxc | 21:18 |
| lynxman | hazmat: best of lucks | 21:19 |
| hazmat | jimbaker, true | 21:19 |
| hazmat | lynxman, let me know if you have any problems | 21:20 |
| lynxman | hazmat: I will, I'm still hammering this and it's only 10PM, plenty of time still :D | 21:21 |
| niemeyer | Almost done with the schema.. | 21:27 |
| lynxman | hazmat: okay one last hurdle, I got it to a point where it doesn't find the ssh keypair | 21:32 |
| lynxman | hazmat: exceptions.LookupError: SSH authorized/public key not found. | 21:32 |
| hazmat | lynxman, you need an ssh-keygen on that machine | 21:38 |
| hazmat | lynxman, ensemble sets up an ssh public key from your homedir onto the remote machines | 21:38 |
| lynxman | hazmat: cool, this being a pristine instance didn't have one, will try that, ty again :) | 21:39 |
| hazmat | lynxman, you can specify it by path or contents in enviroments.yaml.. else it looks for some common ones, this should be in the docs | 21:39 |
| hazmat | its become a faq | 21:39 |
| hazmat | https://ensemble.ubuntu.com/docs/provider-configuration-ec2.html bottom of | 21:39 |
| lynxman | hazmat: excellent, thank you :) | 21:40 |
| fwereade | http digest auth is surprisingly disconcerting to work with | 21:51 |
| fwereade | mainly because I understand the word "nonce" to mean, broadly speaking, "sex offender" | 21:52 |
| hazmat | fwereade, interesting colloquialism | 21:52 |
| fwereade | hazmat: yeah, not a regularly used part of my vocabulary, but one it's suprisingly hard to ignore | 21:53 |
| niemeyer | Schema in Go is finished | 21:59 |
| niemeyer | Will put some docs, and push for review.. | 21:59 |
| niemeyer | But will do a break first | 21:59 |
| hazmat | fwereade, niemeyer, bcsaller, jimbaker quick reminder.. team meeting tomorrow @utc17:00 | 22:07 |
| niemeyer | hazmat: Cheers | 22:15 |
| jimbaker | hazmat, thanks, it's on my calendar | 22:16 |
| === cole_ is now known as cole | ||
| SpamapS | Oddly enough.. at this very moment, I am using ensemble for something work related for the first time.. and its *really* quite helpful. | 23:12 |
| SpamapS | Just being able to say "give me jenkins in the cloud" .. *saweet* | 23:12 |
| niemeyer | SpamapS: Woohay! :) | 23:22 |
| _mup_ | Bug #833432 was filed: Feature Request: allow freezing/thawing an environment <Ensemble:New> < https://launchpad.net/bugs/833432 > | 23:26 |
| jimbaker | SpamapS, that's very nice to hear about jenkins, we will be doing the same for ensemble itself shortly | 23:53 |
| _mup_ | ensemble/go-schema r2 committed by gustavo@niemeyer.net | 23:56 |
| _mup_ | Ported schema verification and coercion logic from Python. (!) | 23:56 |
| SpamapS | jimbaker: I should have OpenID support added to the formula shortly. :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!