| fwereade | niemeyer: heyhey | 12:43 |
|---|---|---|
| niemeyer | fwereade! | 12:44 |
| niemeyer | fwereade: What's up? Ready to rock? | 12:44 |
| fwereade | niemeyer: yep, looking forward to it | 12:44 |
| fwereade | niemeyer: bit miffed my fancy airport pass hasn't arrived yet, I'll be ravelling nearly 24h :/ | 12:44 |
| fwereade | travelling^^^ | 12:44 |
| fwereade | niemeyer: but stlil :) | 12:45 |
| fwereade | ok, I can't type. | 12:45 |
| niemeyer | fwereade: Welcome to my life | 12:45 |
| fwereade | niemeyer: heh :) | 12:47 |
| niemeyer | fwereade: 3h in a bus, just to get started.. | 12:47 |
| fwereade | niemeyer: ouch! | 12:47 |
| niemeyer | fwereade: But I'm happy to do it.. just to enjoy the awesomeness of everyone's presence | 12:48 |
| fwereade | niemeyer: didn't picture that I must admit | 12:48 |
| niemeyer | (honestly) | 12:48 |
| fwereade | niemeyer: oh, likewise :) | 12:48 |
| fwereade | niemeyer: btw, can you bear another rambling chat about appropriate levels of testing? :p | 12:49 |
| niemeyer | fwereade: Absolutely | 12:49 |
| fwereade | niemeyer: the starting point is: https://code.launchpad.net/~fwereade/ensemble/cobbler-find-zookeepers/+merge/69907 | 12:49 |
| fwereade | niemeyer: basically, I'm not sure that directly testing CobblerClient is the right thing to do | 12:50 |
| niemeyer | fwereade: Do you agree code should not stay around untested? | 12:50 |
| fwereade | niemeyer: definitely | 12:50 |
| fwereade | niemeyer: but all that is tested in the context of the tests for the public interactions with the provider itself | 12:51 |
| niemeyer | fwereade: So it should be covered.. testing a public interface as a side-effect of other tests is better avoided if we want to maintain coverage over time | 12:51 |
| fwereade | niemeyer: ah, so you consider CobblerClient to be a public interface? | 12:51 |
| niemeyer | fwereade: There's logic inside that one method, which should be explored in every angle directly, because it's a public interface whose clients can change independently | 12:51 |
| niemeyer | fwereade: Well, is it a private method? | 12:52 |
| niemeyer | fwereade: It surely looks like a well defined encapsulation | 12:52 |
| niemeyer | fwereade: CobblerClient.describe_system | 12:53 |
| fwereade | niemeyer: no, but my impression was that most of the accessible stuff in the provider packages was... accientally public, if you like | 12:53 |
| niemeyer | fwereade: Feels pretty unity :) | 12:53 |
| niemeyer | fwereade: It is internally public precisely because we want to organize it properly and test it adequately | 12:53 |
| niemeyer | fwereade: It is not package public | 12:53 |
| niemeyer | fwereade: In the sense that other packages should not interact with the internals | 12:54 |
| niemeyer | fwereade: There's an analogy I provide every once in a while when this issue comes up | 12:54 |
| fwereade | niemeyer: that does make sense | 12:54 |
| niemeyer | fwereade: We have a gradient | 12:54 |
| fwereade | niemeyer: cool, go on | 12:54 |
| niemeyer | fwereade: and gradients are often well understood by exaggeration | 12:55 |
| niemeyer | fwereade: On one end of the gradient, we test every line with an individual test.. (ugh) | 12:55 |
| niemeyer | fwereade: On the other end of the spectrum, though, we could claim that only the public interface of the _project_ needs testing | 12:55 |
| niemeyer | fwereade: So we test every possible interaction though the command line (!) | 12:56 |
| niemeyer | fwereade: Why is that latter option crazy? | 12:56 |
| fwereade | niemeyer: combinatorial explosion | 12:56 |
| niemeyer | fwereade: Exactly | 12:56 |
| fwereade | niemeyer: which is what I'm concerned about here... | 12:56 |
| niemeyer | fwereade: Which may also be seen as the difficulty of covering every path, and the difficulty of setting up and tearing down the project for so many combinations, and so on | 12:57 |
| niemeyer | fwereade: The same thing can be said about testing good encapsulations through their client users | 12:57 |
| fwereade | niemeyer: I feel like there are a lot of lines where one change will break many tests | 12:57 |
| niemeyer | fwereade: To a lesser degree, of course.. | 12:57 |
| niemeyer | fwereade: Yes, entirely agreed | 12:58 |
| niemeyer | fwereade: and to me preventing that is an artificial goal introduced by the purists of unit testing | 12:58 |
| niemeyer | fwereade: In practice, | 12:58 |
| niemeyer | fwereade: what happens is that changes are done piece-meal.. | 12:58 |
| niemeyer | fwereade: and tested very carefully | 12:59 |
| fwereade | niemeyer: heh, I've one or twice found myself in a situation where I wished I'd followed that advice a bit better ;) | 12:59 |
| niemeyer | fwereade: You'll always know when you change logic which breaks 10 tests instead of 1 | 12:59 |
| niemeyer | fwereade: This is good.. | 12:59 |
| niemeyer | fwereade: It means the semantics we've defined as correct were being asserted | 12:59 |
| niemeyer | fwereade: Now, imagine that tomorrow.. you change the client code to not use all of describe_system's logic | 13:00 |
| niemeyer | fwereade: Which is totally fine | 13:01 |
| niemeyer | fwereade: Suddenly we have entirely uncovered logic | 13:01 |
| niemeyer | fwereade: Which is truly bad, even more in a dynamic language | 13:01 |
| fwereade | niemeyer: well, we have dead code which has the potential to become uncovered logic if we drop the ball on testing in the future, which isn't *quite* as bad | 13:02 |
| fwereade | niemeyer: ...but I take your point | 13:02 |
| === otubo[AFK] is now known as otubo | ||
| fwereade | niemeyer: I'm just finding it a bit painful to be wilfully duplicating code, even if it is test code ;) | 13:03 |
| niemeyer | fwereade: You don't have to duplicate tests.. | 13:04 |
| niemeyer | fwereade: The tests closer to the implementation are generally more detailed than the ones that take it as a client | 13:04 |
| niemeyer | fwereade: You _have_ to cover it all in the tests which are next to the implementation | 13:05 |
| fwereade | niemeyer: so, for example, tests for describe_system handle all the crazy stuff I can imagine | 13:06 |
| niemeyer | fwereade: It's fine to not cover the sub-method details in the tests that just takes other bits of the implementation | 13:06 |
| niemeyer | fwereade: Right, exactly.. you've actually doe that before | 13:06 |
| niemeyer | fwereade: E.g. | 13:06 |
| niemeyer | fwereade: In the MachineProvider interface | 13:06 |
| niemeyer | fwereade: It's just a simple/boring test | 13:06 |
| fwereade | niemeyer: but the tests for things which happen to use describe_system can just assume the happy path, and trust the other tests are solid | 13:06 |
| niemeyer | fwereade: Well, mostly.. e.g. if describe_system has an error path that raises a problem, and the client code from that interface reacts to such error, you have to cover the reaction within the client code's test | 13:07 |
| niemeyer | fwereade: But in that case you're not testing describe_system | 13:08 |
| niemeyer | fwereade: You're testing the client reaction to an eror | 13:08 |
| niemeyer | error | 13:08 |
| fwereade | niemeyer: ...but then we *do* end up having to duplicate the coverage of the details in the distant test | 13:08 |
| niemeyer | fwereade: No, not really | 13:08 |
| niemeyer | fwereade: The test for describe_system will cover its own behavior which cause the error to be raised | 13:08 |
| niemeyer | fwereade: The client test will test the reaction to the fact describe_system raised an error.. | 13:09 |
| niemeyer | fwereade: Simple example: | 13:09 |
| fwereade | niemeyer: ok, but we still need to mock all the external interactions which would cause that error, right? | 13:09 |
| niemeyer | fwereade: describe_system could have 10 reasons why it would raise OhMyGod | 13:09 |
| niemeyer | fwereade: You have to cover it all in its tests | 13:09 |
| fwereade | niemeyer: ...ok, yes, I only need to hit one of the sad paths in a distant test | 13:09 |
| niemeyer | fwereade: If the client code has to take care of OhMyGod, you just the fact it can cope with it | 13:09 |
| niemeyer | just test | 13:10 |
| fwereade | niemeyer: it just feels like, in the average case, foo_method will have one or two reasons for raising OhMyGod, and one reason to raise Gadzooks, and one to raise JiminyJillikers | 13:10 |
| niemeyer | fwereade: Preferably, not mocking | 13:10 |
| niemeyer | fwereade: But we've covered that | 13:10 |
| niemeyer | fwereade: Are you saying you have an abstraction that isn't useful and should be removed? I can buy that :-) | 13:11 |
| fwereade | niemeyer: (indeed, but with external systems we're kinda forced down that path) | 13:11 |
| fwereade | niemeyer: [JiminyJillikers] ...and so the only stuff we can avoid is one of the OhMyGod paths ...and that applies for every single thing that uses foo_method | 13:13 |
| fwereade | niemeyer: I don't quite follow the abstraction comment | 13:14 |
| fwereade | niemeyer: anyway, I think you have clarified your position, and I'm happy to follow your lead; it's just taking me a little while to get used to the project style, it's rather different to what I'm used to | 13:16 |
| fwereade | niemeyer: thanks :) | 13:16 |
| niemeyer | fwereade: No problem, and I know where you're coming from | 13:17 |
| niemeyer | fwereade: In part, I'd be way less worried about that if we were not using a dynamic language | 13:17 |
| niemeyer | fwereade: Uncovered code in a dynamic language is a bomb | 13:17 |
| niemeyer | fwereade: I'd rather have duplication than increase the risks of having untouched logic | 13:18 |
| fwereade | niemeyer: yeah, that's a perfectly reasonable position :) | 13:18 |
| fwereade | niemeyer: well, then, I've got some tests to write :) | 13:19 |
| fwereade | niemeyer: (and I think I'll be beefing up the coverage in some of the pre-approved branches stacked on top of this one before I merge them, too) | 13:20 |
| niemeyer | fwereade: That sounds awesome indeed, thanks a lot, and sorry for the extra pain | 13:20 |
| fwereade | niemeyer: don't worry, solid testing is worth a bit of extra typing... you make solid arguments for the strategy, and all my objections are essentially what-ifs :) | 13:28 |
| fwereade | niemeyer: I think I will need to do quite a lot of rearrangement though, it'll take a little while :( | 13:30 |
| niemeyer | fwereade: No worries.. you've been cranking in a good pace | 13:31 |
| niemeyer | fwereade: If you have to take a moment or two to rearrange in a way you feel is more suitable for the problem we have, that sounds positive | 13:32 |
| fwereade | niemeyer: I'm suddenly not even sure it's a good idea: I *could* test some of the more distant things a bit less, but I suspect the best time to fix that is in the future | 13:34 |
| fwereade | niemeyer: I'll see how it goes | 13:34 |
| niemeyer | fwereade: That sounds reasonable too | 13:35 |
| niemeyer | fwereade: I'm not personally worried that you might be testing too much :-) | 13:36 |
| fwereade | niemeyer: haha :) | 13:36 |
| niemeyer | "mgo enables us to blazingly serve more than 1.000.000 book covers a day while reducing our servers load" - Feedbooks.com | 13:37 |
| niemeyer | Awesomeness | 13:37 |
| fwereade | niemeyer: cool D: | 13:39 |
| fwereade | er, :D | 13:39 |
| hazmat | g'morning | 13:44 |
| hazmat | argh.. just lost my reply to namespaces.. | 13:45 |
| hazmat | aha.. there's still a copy in a temp file | 13:49 |
| noodles775 | Is there a relation-set (equivalent of relation-get?). I'm just trying to find in the docs how I provide my ip to the postgresql db-relation-changed hook from my own hook? | 13:58 |
| RoAkSoAx | fwereade: howdy!! | 14:01 |
| fwereade | RoAkSoAx: heyhey :) | 14:01 |
| niemeyer | noodles775: Yeah, relation-set is exactly the name | 14:01 |
| noodles775 | Sweet, trying now. | 14:01 |
| RoAkSoAx | fwereade: how's it going | 14:01 |
| niemeyer | noodles775: This document may be helpful: https://ensemble.ubuntu.com/docs/formula.html | 14:02 |
| niemeyer | noodles775: Look for relation-set there | 14:02 |
| fwereade | RoAkSoAx: not too shabby... got a lot of tests to write this afternoon to firm up some of my languishing branches | 14:02 |
| fwereade | RoAkSoAx: and yourself? | 14:02 |
| RoAkSoAx | fwereade: pretty good | 14:02 |
| RoAkSoAx | fwereade: so we have ensemble deploying | 14:03 |
| RoAkSoAx | fwereade: then only things that seems to be complaining about is not yet have the shutdown methods | 14:03 |
| fwereade | RoAkSoAx: in theory, you shouldn't have to worry about those, because they exist | 14:04 |
| noodles775 | niemeyer: Ah, I was searching https://ensemble.ubuntu.com/docs/write-formula.html (where it's not mentioned). Thanks. | 14:04 |
| RoAkSoAx | fwereade: well, when deploying a machine, you can see in the provision log that there's an error and the code fails to execute :) | 14:04 |
| fwereade | RoAkSoAx: sadly they're (1) still in the process of being turned into something I can propose (trying to avoid all duplication with ec2) and (2) stacked up behind branches that aren't accepted yet | 14:04 |
| fwereade | RoAkSoAx: why do we need to shut stuff down when we're deploying? | 14:05 |
| RoAkSoAx | fwereade: yeah no worries, it is not a deal braker for me at the moment as I can still deploy | 14:05 |
| fwereade | RoAkSoAx: cool :D | 14:05 |
| m_3 | noodles775: here's an example of that very task... http://pastebin.com/utdiAHSs | 14:05 |
| RoAkSoAx | fwereade: I don't, but when I deploy it executes one of those functions for some reason | 14:05 |
| RoAkSoAx | fwereade: and I have to restart ensemble to be able to actually deploy | 14:06 |
| fwereade | RoAkSoAx: that's bizarre... | 14:06 |
| RoAkSoAx | on the zookeeper | 14:06 |
| RoAkSoAx | fwereade: indeed | 14:06 |
| fwereade | everyone else: any guesses? | 14:06 |
| RoAkSoAx | fwereade: other than that, I found an error of complaining that "something needs to be str instead of unicode" when doing a "PUT" | 14:06 |
| noodles775 | m_3: Ah, thanks! | 14:06 |
| fwereade | RoAkSoAx: oof, good catch | 14:06 |
| RoAkSoAx | fwereade: and that something is the url | 14:07 |
| fwereade | RoAkSoAx: would you file a bug for that one please, that stuff's in trunk now | 14:07 |
| fwereade | RoAkSoAx: I presume it doesn't happen all the time? | 14:08 |
| RoAkSoAx | fwereade: no only when trying to store the formula on the webdav | 14:08 |
| RoAkSoAx | fwereade: what I did is simply url = str(url) | 14:08 |
| fwereade | RoAkSoAx: the formula url is always unicode then? | 14:08 |
| RoAkSoAx | fwereade: appears to be | 14:09 |
| fwereade | RoAkSoAx: good to know, thanks | 14:09 |
| fwereade | RoAkSoAx: hmm, yeah, there are unicode tests for the s3 FileStorage :/ | 14:09 |
| * fwereade hangs his head | 14:10 | |
| hazmat | fwereade, the unicode gets introduced by yaml.load | 14:11 |
| fwereade | hazmat: ah, makes sense | 14:11 |
| hazmat | against the formula metadata, used for constructing the key to storage | 14:11 |
| m_3 | noodles775: sure thing... lemme know if I can help | 14:12 |
| noodles775 | m_3: I wonder if it's even worth including that example in the README.markdown? | 14:13 |
| m_3 | noodles775: we're workign on the best way to document formulas and relation interfaces | 14:16 |
| noodles775 | m_3: Great - let me know if I can help. | 14:16 |
| m_3 | noodles775: that particular interface is simple enough to put it in the readme... good idea, I'll do that for now | 14:16 |
| _mup_ | Bug #821493 was filed: tilda-expansion for deploy repository value <Ensemble:New> < https://launchpad.net/bugs/821493 > | 14:22 |
| RoAkSoAx | fwereade: ok, so I'll prepare a branch for you | 14:23 |
| RoAkSoAx | fwereade: so that we can have a branch ready for next week | 14:24 |
| RoAkSoAx | fwereade: which I presume the shutdown stuff willa lso be there | 14:24 |
| fwereade | RoAkSoAx: cool; I hope I'll get to it before Monday, but it won't be today :( | 14:24 |
| RoAkSoAx | fwereade: no worries | 14:24 |
| RoAkSoAx | fwereade: we just need a working branch by monday to work on that all week | 14:24 |
| niemeyer | I've got 5 calls this morning, 2 door bells, 1 family visit, ... slightly harder to focus today. | 14:29 |
| noodles775 | m_3: Hrm, I'm not sure what's ambiguous? http://paste.ubuntu.com/659326/ | 14:38 |
| * noodles775 looks more closely at the error message. | 14:38 | |
| m_3 | noodles775: there're two relations in postgres | 14:40 |
| m_3 | noodles775: db and db-admin | 14:40 |
| m_3 | noodles775: so you need something like 'ensemble add-relation postgres:db ogt | 14:41 |
| m_3 | ' | 14:41 |
| noodles775 | m_3: I see, thanks. | 14:41 |
| m_3 | noodles775: did the relation complete? | 14:48 |
| === otubo is now known as otubo[AFK] | ||
| m_3 | kim0: sorry, didn't see that there were other sheets in that workbook | 15:10 |
| kim0 | it's ok .. too much is better than too little :) | 15:11 |
| m_3 | kim0: move stuff whereever you need to | 15:11 |
| RoAkSoAx | fwereade: ping | 15:15 |
| fwereade | RoAkSoAx: pong | 15:15 |
| RoAkSoAx | fwereade: what does this do and is it really necessaru? | 15:15 |
| RoAkSoAx | http://pastebin.ubuntu.com/659354/ | 15:15 |
| RoAkSoAx | fwereade: cause if I return connect.run() it still works | 15:16 |
| fwereade | RoAkSoAx: I'm not totally convinced by that _run_operation thing, I feel we should either wrap it around everything or skip it entirely | 15:16 |
| RoAkSoAx | fwereade: ok, so in the orchestra stuff will only return connect.run() then (which is what I'm using right now | 15:17 |
| robbiew | hazmat: ping | 15:18 |
| fwereade | RoAkSoAx: you certainly don't need to worry about it in your tree, I'll figure out what to do with it when I have to ;) | 15:18 |
| RoAkSoAx | fwereade: ok cool. Do you want me to include the url = str(url) on the branch? | 15:18 |
| fwereade | RoAkSoAx: yeah, I think it's my responsibility to make sure I do the right thing | 15:19 |
| hazmat | robbiew, pong | 15:19 |
| robbiew | hazmat: so I'm an idiot and forgot about our call...again | 15:19 |
| robbiew | hazmat: given we are meeting all next week and just spoke...I don't have anything critical, but if you want to talk...I'm game | 15:20 |
| hazmat | robbiew, no worries, i've got an open time today, if you want to do it adhoc today, else next week | 15:20 |
| hazmat | robbiew, next week sounds good | 15:20 |
| robbiew | cool deal....and bring shorts!!! | 15:20 |
| robbiew | high today: 107 | 15:21 |
| hazmat | ugh.. | 15:21 |
| * hazmat plans on running at high speeds between a/c environments | 15:21 | |
| robbiew | you could die in that run | 15:22 |
| robbiew | lol | 15:22 |
| m_3 | wow... that's impressive | 15:22 |
| * m_3 trying to imagine laptops and power strips at the pool bar | 15:24 | |
| hazmat | otoh, i guess i should be used to it by now, washington, dc hit a heat index of 118 a few weeks ago, high humidity, actual temp around 105.. lots of hot air in dc ;-) | 15:24 |
| robbiew | hazmat: heh, yeah | 15:33 |
| robbiew | I have family there, and used to go every Summer as a kid | 15:33 |
| robbiew | the only difference is that in the evening, it generally cools down....not here :/ | 15:33 |
| RoAkSoAx | fwereade: lp:~andreserl/+junk/ensemble-sprint | 15:34 |
| robbiew | some towns/cities have gone 40+ days of +100....damn dust bowl | 15:34 |
| RoAkSoAx | here it is 91F with 65% humidity | 15:35 |
| robbiew | yuk..that's jungle heat | 15:53 |
| heckj | sounds like a US midwest temp, except maybe a bit dry... | 15:55 |
| RoAkSoAx | I wish I was leaving right in front of the ocean | 15:56 |
| niemeyer | Lunch time here | 16:22 |
| fwereade | eod, later all :) | 16:40 |
| robbiew | fwereade: peace out! | 16:44 |
| kirkland | howdy peeps ... in case you missed it elsewhere, here's a good read on Orchestra + Ensemble http://blog.dustinkirkland.com/2011/08/formal-introduction-to-ubuntu-orchestra.html | 17:01 |
| hazmat | kirkland, nice | 17:04 |
| kirkland | kim0: ping | 17:27 |
| robbiew | bcsaller: hey...just realized I missed our call...but given we just spoke as a team and have all next week together, I figured it was cool | 17:31 |
| * robbiew is batting two for two on missing 1:1s | 17:31 | |
| * robbiew notes not to reschedule 1:1s on Fridays | 17:31 | |
| bcsaller | robbiew: no problem, we'll see each other next week anyway | 17:33 |
| robbiew | cool deal...well, not "cool" heh | 17:34 |
| === otubo[AFK] is now known as otubo | ||
| _mup_ | ensemble/security-connection r290 committed by kapil.thangavelu@canonical.com | 18:19 |
| _mup_ | ssh client uses single inheritance to get policy enforcement. | 18:19 |
| niemeyer | kirkland: Very nice post | 18:22 |
| _mup_ | ensemble/security-connection-redux r287 committed by kapil.thangavelu@canonical.com | 18:22 |
| _mup_ | merge security connection redux and trunk | 18:22 |
| kirkland | Nicke: thanks! | 18:22 |
| _mup_ | ensemble/security-groups r292 committed by kapil.thangavelu@canonical.com | 18:26 |
| _mup_ | resolve conflict from security-connection merge. | 18:26 |
| _mup_ | ensemble/security-otp-principal r295 committed by kapil.thangavelu@canonical.com | 18:27 |
| _mup_ | resolve conflict from security-connection merge | 18:27 |
| _mup_ | ensemble/security-acl r300 committed by kapil.thangavelu@canonical.com | 18:29 |
| _mup_ | resolve conflict from security-connection merge | 18:29 |
| _mup_ | ensemble/states-with-principals r317 committed by kapil.thangavelu@canonical.com | 18:29 |
| _mup_ | resolve conflict from security-connection merge | 18:29 |
| _mup_ | ensemble/trunk-merge r275 committed by kapil.thangavelu@canonical.com | 18:30 |
| _mup_ | merge trunk | 18:30 |
| _mup_ | ensemble/security-groups r294 committed by kapil.thangavelu@canonical.com | 18:43 |
| _mup_ | address review comments, conflicts are silent (same goal state reached), duplicate state creation errors are runtime-exceptions. | 18:43 |
| _mup_ | ensemble/security-acl r302 committed by kapil.thangavelu@canonical.com | 18:51 |
| _mup_ | resolve security-group merge conflict. | 18:51 |
| _mup_ | Bug #821621 was filed: add custom commands to the cli <Ensemble:New> < https://launchpad.net/bugs/821621 > | 18:55 |
| _mup_ | ensemble/trunk r295 committed by kapil.thangavelu@canonical.com | 19:04 |
| _mup_ | merge security-groups [r=niemeyer,fwereade][f=814260] | 19:04 |
| _mup_ | Implements a security group as a stored/persistent principal | 19:04 |
| _mup_ | with membership denoting acl to utilize the group node, | 19:04 |
| _mup_ | and thus credential usage on a connection. | 19:04 |
| hazmat | hmm. i mislabed that last merge | 19:10 |
| hazmat | i just accidentally committed security-connection with the commit message from security-groups.. | 19:11 |
| hazmat | not a big deal practically, but the commit message is wrong, just curious if there is a way to fix the message | 19:11 |
| niemeyer_ | hazmat: No way to fix it | 19:18 |
| niemeyer_ | hazmat: You'd have to uncommit.. | 19:18 |
| niemeyer_ | hazmat: The potential disaster of doing so isn't worth the trouble | 19:18 |
| hazmat | its a remote repo, i'll just note in the next commit message | 19:18 |
| niemeyer_ | hazmat: THat's a good plan | 19:19 |
| _mup_ | ensemble/trunk r296 committed by kapil.thangavelu@canonical.com | 19:19 |
| _mup_ | merge security-groups [r=niemeyer,fwereade][f=814260] | 19:19 |
| _mup_ | Previous merge (r295) was of security-policy-connection | 19:19 |
| _mup_ | Implements a security group as a stored/persistent principal | 19:19 |
| _mup_ | with membership denoting acl to utilize the group node, | 19:19 |
| _mup_ | and thus credential usage on a connection. | 19:19 |
| _mup_ | ensemble/states-with-principals r319 committed by kapil.thangavelu@canonical.com | 19:21 |
| _mup_ | resolve conflict from merge of security-group | 19:21 |
| _mup_ | ensemble/security-policy-rules-redux r325 committed by kapil.thangavelu@canonical.com | 19:23 |
| _mup_ | resolve conflict from security-group merge | 19:23 |
| _mup_ | ensemble/security-policy-rules-redux r326 committed by kapil.thangavelu@canonical.com | 19:27 |
| _mup_ | resolve conflict with security-groups merge | 19:27 |
| === niemeyer_ is now known as niemeyer | ||
| hazmat | niemeyer, what do you think about using blueprints for the next milestone | 19:52 |
| hazmat | i'd like a better way of capturing working in progress on multi-branch features than what the kanban view gives us | 19:52 |
| hazmat | s/working/work | 19:53 |
| niemeyer | hazmat: I feel we shouldn't introduce additional burden without taking something out now | 19:53 |
| niemeyer | hazmat: For features, we have specs + a branch per change + a bug per branch + a merge proposal per branch | 19:54 |
| niemeyer | hazmat: We need a holistic view on that workflow and to understand what's the role of any additions, before going into it | 19:54 |
| niemeyer | hazmat: The conversation about the task management the other day might solve your worries on that area | 19:56 |
| niemeyer | hazmat: But if we introduce it, my suggestion was to replace the kanban and the hand management of MP state out | 19:57 |
| hazmat | niemeyer, good point, i'm abusing bug tags to keep track of all the security work now, but we probably don't need more process atm | 19:57 |
| niemeyer | hazmat: and bugs too, actually | 19:57 |
| hazmat | niemeyer, what if the kanban viewhad management of state inline to the ui | 19:57 |
| niemeyer | hazmat: When the bug is artificial | 19:57 |
| niemeyer | hazmat: Wouldn't solve.. our current workflow lacks information ATM.. doing the same workflow in a different location wouldn't solve the issue | 19:58 |
| niemeyer | hazmat: Nowhere we track the "This is pending a re-review from Kapil", nor do we have a way to say "These are the things the team is waiting on you to do" | 19:59 |
| niemeyer | hazmat: So, my ideal change would be taking Kanban + Artificial bugs + MP state management out, and replace it by a _good_ task management + calendar software that includes task assignment and team-scoped view | 20:00 |
| niemeyer | hazmat: I don't have a good proposal for that system yet, but I'm looking | 20:01 |
| niemeyer | hazmat: We can end up implementing it, but I'd rather not | 20:01 |
| hazmat | niemeyer, i mean pivotal tracker is nice.. but i think at the end of the day, we'll probably need something custom ontop of lp | 20:01 |
| niemeyer | hazmat: Or less of Launchpad | 20:03 |
| niemeyer | hazmat: For the project management aspects | 20:03 |
| hazmat | niemeyer, perhaps but unless its a tool that works well with an opensource community, a commercial tool would need to allow participation from the public, and ideally see our branches on lp, i'm not sure its ever going to outweigh lp | 20:05 |
| hazmat | and then we just end up dividing data | 20:06 |
| hazmat | better to build the ui we want onto of lp imo | 20:06 |
| niemeyer | hazmat: We have zero community contributors right now | 20:07 |
| niemeyer | hazmat: Integrated into the workflow of development | 20:07 |
| niemeyer | hazmat: and if/when we do have, we can certainly sponsor them in whatever system we have | 20:07 |
| niemeyer | hazmat: There's really no friction in that regard | 20:07 |
| hazmat | niemeyer, we're just beginning our community.. every road block to participation, halfs (at least) participation. | 20:07 |
| hazmat | theirs tons of market/ui architect research to support that | 20:08 |
| niemeyer | hazmat: Sorry, I don't really understand the point you're making | 20:08 |
| niemeyer | hazmat: How's a good task/project management solution bad in any way for the community? | 20:09 |
| niemeyer | hazmat: I'm trying to take the burden out of workflow, simplifying it and making it more enjoyable.. hard to believe the community with be bothered with it. | 20:09 |
| hazmat | niemeyer, your removing the relevant word, commercial tools for ensemble, need to be publicly available, commercial projects are typically billed against customers, we need public access to decrease barriers of entry, | 20:11 |
| hazmat | s/commercial project tools | 20:11 |
| niemeyer | hazmat: Heh | 20:11 |
| niemeyer | hazmat: Let's start by not using EC2 then. | 20:11 |
| niemeyer | hazmat: Or Google | 20:12 |
| hazmat | niemeyer, commercial resources consumed as the cost of using the project are fine, the later is atm private team meetings | 20:12 |
| niemeyer | hazmat: Google, search.. | 20:12 |
| niemeyer | hazmat: Gmail.. Google+ | 20:12 |
| hazmat | is a publicly available tool | 20:13 |
| niemeyer | hazmat: Yes.. and I'm saying we'll make whatever tool we use available to anyone who wants to participate | 20:13 |
| niemeyer | hazmat: How's that different? | 20:13 |
| niemeyer | hazmat: We're producing software.. under great licenses | 20:14 |
| niemeyer | hazmat: We're in a public channel.. our list is public.. Ubuntu is open | 20:14 |
| niemeyer | hazmat: If we have to use a commercial tool to handle a less relevant aspect of the project management, we will | 20:15 |
| hazmat | niemeyer, that's not what you said at least re project management tools, afaics, correct me if i'm wrong | 20:15 |
| niemeyer | hazmat: Just like we use Google search, and EC2 | 20:15 |
| niemeyer | hazmat: and Google+, and used Skype for conferences | 20:15 |
| hazmat | private team meetings aren't the issue, the work that tracks what in release is | 20:15 |
| niemeyer | hazmat: We're pushing the envelope making good free software available for people, and using these tools does not compromise our goal in any way | 20:16 |
| hazmat | what!? | 20:16 |
| niemeyer | Erm.. | 20:16 |
| niemeyer | Sounds like that conversation isn't being positive. | 20:16 |
| hazmat | i don't think we're pushing the envelope in the scope of free software | 20:17 |
| niemeyer | Oh, really? You don't think Ensemble is pushing the envelope in terms of free software? | 20:17 |
| * niemeyer misses the point | 20:17 | |
| hazmat | we're creating a new unique tool that's great.. but pushing the envelope of actually putting out free softare? | 20:17 |
| niemeyer | hazmat: Isn't Ensemble free software? I'm lost now.. | 20:17 |
| hazmat | but we're talking about making the process less free to the public | 20:18 |
| hazmat | and pushing the envelope? | 20:18 |
| niemeyer | hazmat: And I'm talking about Ensemble, the product we develop. | 20:18 |
| hazmat | llvm pushes the envelope, sqlite pushes the envelope, openstack is pushing the envelope... many projects push the envelope.. all free, all quite easy to contribute to, because they have public tools, i think your conflating the question.. | 20:19 |
| hazmat | comment actually, that any tool we use should be publicly available | 20:20 |
| hazmat | to enable participation | 20:20 |
| niemeyer | hazmat: All of these push the envelope, and Ensemble does as well. | 20:20 |
| hazmat | niemeyer, that's not the question.. or the discussion. let's not make it one. i agree. | 20:20 |
| hazmat | the question is how do we get better tools, that do what we want? | 20:21 |
| niemeyer | hazmat: That's my point. My goal is to develop Ensemble, and to make it rock, and to make it free. | 20:21 |
| niemeyer | hazmat: If I have to use Google search for that, even though it's closed source software, I will. | 20:21 |
| niemeyer | hazmat: If I have to use a closed source communication software (or hardware, for that matter) so that I can communicate with people, I will. | 20:21 |
| hazmat | to enable or foster a development community those tools that we use to produce it should be available for public participation. | 20:21 |
| niemeyer | hazmat: I'm not solving those problems.. I'm not interested in developing good task management software right now (maybe some day). | 20:22 |
| robbiew | I think the issues are being mixed up | 20:22 |
| niemeyer | hazmat: I am very interested in the community. If you think that to build a community you need to be using open source software in all edges, you're very mistaken. | 20:22 |
| niemeyer | hazmat: Google+ has 25M users today. | 20:22 |
| niemeyer | hazmat: If you want to continue that conversation, let's do so next week. | 20:23 |
| hazmat | niemeyer, i didn't say opensource at the edges, i said publicly available | 20:23 |
| robbiew | right, and Google+ doesn't require users to pay for it...which is where I think hazmat is going | 20:23 |
| robbiew | it's publicly available to use | 20:23 |
| hazmat | the data we have and automatically collect at lp is valuable | 20:23 |
| niemeyer | robbiew, hazmat: and I just said repeatedly we'll make them available to anyone who's interested in participating. | 20:23 |
| niemeyer | </rant> | 20:24 |
| robbiew | right...i think you are agreeing more than you know ;) | 20:24 |
| hazmat | niemeyer, "<niemeyer> hazmat: Yes.. and I'm saying we'll make whatever tool we use available to anyone who wants to participate" is not the same as publicly available | 20:24 |
| hazmat | its selective | 20:24 |
| niemeyer | hazmat: "anyone" is selective.. please stop the bikeshed | 20:24 |
| hazmat | niemeyer, i don't think its a bikeshed.. although perhaps a misunderstanding.. the difference between people we select ("make available") and register in a tool vs. available to non-registered users (aka anyone. the public) is a rather different selection criteria. | 20:28 |
| niemeyer | hazmat: "anyone" != "people we select".. let's please stop. There's no tool. | 20:29 |
| niemeyer | hazmat: Basecamp allows projects to be available openly, as a trivial example of the lack of reason for any kind of discussion before we have a proposal. | 20:31 |
| hazmat | niemeyer, sounds good, sometimes its good to have evaluation criteria before a proposal begins | 20:33 |
| niemeyer | hazmat: Heh.. thanks for bashing my lack of proposal to death. | 20:33 |
| niemeyer | I'm stepping out for the day.. I'll see you guys next week. | 20:45 |
| _mup_ | ensemble/security-otp-principal r298 committed by kapil.thangavelu@canonical.com | 21:58 |
| _mup_ | speling suggestions and use of runtimerror instead of valueerror per review comments. | 21:58 |
| _mup_ | ensemble/security-otp-principal r299 committed by kapil.thangavelu@canonical.com | 22:09 |
| _mup_ | update tests with new exceptions | 22:09 |
| _mup_ | ensemble/trunk r297 committed by kapil.thangavelu@canonical.com | 22:15 |
| _mup_ | merge security-otp-principal [r=niemeyer,fwereade][f=814320] | 22:15 |
| _mup_ | Implements an OTP Principal, that stores the credentials | 22:15 |
| _mup_ | for a named persistent principal in a node protected | 22:15 |
| _mup_ | by an ACL referencing a separate OTP credentials. The | 22:15 |
| _mup_ | credentials and path to the OTP node can be serialized | 22:15 |
| _mup_ | and passed around to their consumption target. The OTP | 22:15 |
| _mup_ | node is destroyed upon API usage. | 22:15 |
| _mup_ | This is not a true OTP, but the best we can do atm without | 22:15 |
| _mup_ | extension of zookeeper. See bug: 819379 for tracking this issue | 22:15 |
| _mup_ | and merge proposal comments on this branch for further reference. | 22:15 |
| _mup_ | https://code.launchpad.net/~hazmat/ensemble/security-otp-principal/+merge/68754 | 22:15 |
| _mup_ | ensemble/states-with-principals r321 committed by kapil.thangavelu@canonical.com | 22:51 |
| _mup_ | make acl.grants for the same principal additive in nature, removes a potential source of conflict. | 22:51 |
| _mup_ | ensemble/security-acl r304 committed by kapil.thangavelu@canonical.com | 22:55 |
| _mup_ | make acl.grants for the same principal additive in nature, removes a potential source of conflict. | 22:55 |
| _mup_ | ensemble/trunk r298 committed by kapil.thangavelu@canonical.com | 22:58 |
| _mup_ | merge security-acl [r=niemeyer,fwereade][f=816108] | 22:58 |
| _mup_ | Implement an ACL abstraction for manipulating a zk node's ACL. | 22:58 |
| hazmat | have a good weekend folks, cheers | 22:59 |
| niemeyer | Time for pre-sprint bill-paying | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!