| kim0 | Morning everyone | 09:15 |
|---|---|---|
| * hazmat gives up on unity | 14:15 | |
| hazmat | are there any union or overlay filesystems for which you can capture a useable delta against the base fs | 14:19 |
| niemeyer | Hey Ensemblers! | 14:27 |
| kim0 | hazmat: aufs ? | 15:13 |
| _mup_ | ensemble/update-install-docs r242 committed by kapil.thangavelu@canonical.com | 15:37 |
| _mup_ | factor out source installation into a developer-install doc | 15:37 |
| hazmat | kim0 i don't think any of them real expose deltas is a particular useful way.. aufs has some internal files it uses for inode pointers, which it looks like which make it conceivable but potentially brittle | 15:39 |
| hazmat | s/real/really | 15:39 |
| kim0 | zfs snapshots with 'zfs send' ? :) | 15:42 |
| hazmat | kim0, hmm.. not sure if thats appropriate, there are some nice time slider interfaces for zfs auto snapshot integrated into nautilus but snapshot browsing is a pretty easy.. what i was wondering about was some sort of preview mode against a hook, that could take a snapshot of the fs, and the running processes, before the hook, compared to an after hook environment, that could be presented to an end user as the actions of a hook | 15:45 |
| hazmat | along with the delta of changed relation data | 15:45 |
| kim0 | system wide diff | 15:46 |
| kim0 | pff | 15:46 |
| kim0 | hazmat: and it'd have to work on regular filesystems too right? (ext3/4?) | 15:46 |
| hazmat | kim0, indeed, and its not clear to me if that's either realistic or useful by itself, the process changes is rather difficult to capture meaningfully, if there's an internal change in a process state.. | 15:47 |
| hazmat | just brainstorming on what dry run might look like | 15:48 |
| kim0 | Yeah | 15:48 |
| kim0 | perhaps it might be simpler to try hooking runs of service/cp/mv ? | 15:48 |
| kim0 | but that list is never complete | 15:48 |
| hazmat | kim0, indeed.. some hooks might not use shell as well, but an arbitrary binary (formula in go? ;-) we'd have to hook syscalls and presenting that an intelligible diff to an admin might be a challenge | 15:51 |
| kim0 | hazmat: or perhaps another way to look at it, might be to request prepending commands with a sudo like prefix, just like (svn mv, svn rm) ...etc Instead of allowing running arbitrary executables .. pros and cons of course | 15:53 |
| hazmat | kim0, its also unclear since its a dynamic system, if such a preview is truly reliable.. a remote state change could change the local behavior from the preview at any time. | 15:55 |
| kim0 | yeah, it's a hard problem :) | 15:55 |
| _mup_ | ensemble/trunk r247 committed by kapil.thangavelu@canonical.com | 16:15 |
| _mup_ | merge resolved-install-should-start [r=niemeyer][f=794129] | 16:15 |
| _mup_ | Resolving an install_error should automatically attempt a transition to start | 16:15 |
| _mup_ | if the install error is resolved successfully. | 16:15 |
| === deryck_ is now known as deryck | ||
| niemeyer | Nice review queue again | 16:42 |
| _mup_ | ensemble/expose-provision-service-hierarchy r272 committed by jim.baker@canonical.com | 16:49 |
| _mup_ | More corner cases dealing with concurrently removed services | 16:49 |
| jimbaker` | niemeyer, could you take a look at expose-hook-commands in review - it's independent of the two other branches i'm working on | 17:00 |
| niemeyer | jimbaker`: Yeah, will clear it up today | 17:00 |
| jimbaker` | i also just adjusted expose-provision-service-hierarchy to indicate it's WIP w/ the changes in expose-watch-exposed-flag, should have done that earlier | 17:01 |
| jimbaker` | the good thing about that is that the move to the stateful api did in fact unexpose some subtle timing bugs | 17:02 |
| niemeyer | jimbaker`: Interesting | 17:07 |
| niemeyer | I'll get some lunch | 17:11 |
| _mup_ | ensemble/expose-provision-service-hierarchy r273 committed by jim.baker@canonical.com | 17:11 |
| _mup_ | test_service_unit_watching now loops properly | 17:11 |
| kim0 | niemeyer: hey, let's do the sync'up meeting in 90mins | 17:36 |
| kim0 | Another thing .. I'll need some help from the team to identify bitesized bug | 17:37 |
| kim0 | Basically, I'll start a campaign to go out and get people interested in contributing to Ensemble. For that, we'd probably need a list of bitesized bugs that we can point people to | 17:38 |
| kim0 | This has worked well for Unity, so hopefully for us as well | 17:38 |
| kim0 | so we'd need a tag a few bugs as "bitesized". Or maybe file new bugs if appropriate. This can be easy to fix bugs, or nice to haves that are not too uegent for the team and are low barrier for a newcomer | 17:39 |
| kim0 | if we can have 10-15 bugs tagged/created, that'd be awesome | 17:40 |
| kim0 | let me know what you guys think | 17:40 |
| kim0 | I'll probably file some new bugs for important formulas I'd like to see written, and I'll pimp them to the respective communities. But where I need the help most, is code bugs (improve test coverage, fix a small bug ..etc) | 17:46 |
| _mup_ | ensemble/expose-provision-service-hierarchy r274 committed by jim.baker@canonical.com | 17:48 |
| _mup_ | Remaining tests now also loop | 17:48 |
| jimbaker` | kim0, meeting on #ubuntu-cloud in 30 minutes, right? | 18:30 |
| kim0 | jimbaker`: yeah | 18:31 |
| jimbaker` | kim0, sounds good | 18:31 |
| _mup_ | ensemble/set-transitions r230 committed by bcsaller@gmail.com | 18:36 |
| _mup_ | merge forward | 18:36 |
| kim0 | uno, dos, tres | 19:00 |
| _mup_ | ensemble/expose-provision-service-hierarchy r275 committed by jim.baker@canonical.com | 19:01 |
| _mup_ | Assert expected log lines | 19:01 |
| kim0 | niemeyer: hazmat bcsaller jimbaker`: anyone up for the meeting | 19:01 |
| kim0 | #Ubuntu-Cloud please | 19:01 |
| niemeyer | kim0: Here, and there | 19:01 |
| kim0 | cool | 19:01 |
| jimbaker` | kim0, over on #ubuntu-cloud, waiting for the meeting to start :) | 19:02 |
| niemeyer | jimbaker`: The meeting ended.. | 19:20 |
| jimbaker` | niemeyer, yes | 19:21 |
| niemeyer | jimbaker`: I though you were going to say something? | 19:21 |
| kim0 | koolhead17: hey o/ | 19:21 |
| koolhead17 | kim0: hey man. | 19:22 |
| jimbaker` | niemeyer, didn't really have anything to add to what was said about the progress on expose | 19:22 |
| kim0 | koolhead17: how's it going buddy | 19:22 |
| koolhead17 | just happy happy :) | 19:22 |
| kim0 | koolhead17: haha :) | 19:23 |
| jimbaker` | there are some interesting details about ensemble internals, but not germane for that particular meeting i think | 19:23 |
| koolhead17 | kim0: and yes puppet CTO follows all the tweets wit hashtag puppet :D | 19:23 |
| kim0 | koolhead17: that would make sense :) | 19:24 |
| kim0 | koolhead17: working on some cool stuff lately ? | 19:24 |
| hazmat | jimbaker`, perhaps for the standup then.. | 19:24 |
| koolhead17 | kim0: yes. KVM and CFengine | 19:24 |
| koolhead17 | :D | 19:24 |
| jimbaker` | hazmat, of course | 19:24 |
| hazmat | bcsaller, niemeyer, jimbaker` standup time? | 19:25 |
| niemeyer | Yep, let's go | 19:25 |
| koolhead17 | hazmat: niemeyer jimbaker` hello all :P | 19:25 |
| jimbaker` | niemeyer, hazmat sounds good | 19:25 |
| * koolhead17 wants to meet someone from ensemble team in berlin :) | 19:25 | |
| bcsaller | in mumble | 19:25 |
| kim0 | koolhead17: so what exactly are you doing with those I'm interested :) | 19:25 |
| koolhead17 | kim0: in KVM learning the networking modes and CFengine just started and finding very confusing. | 19:26 |
| koolhead17 | you were right about CFengine | 19:27 |
| koolhead17 | :P | 19:27 |
| kim0 | koolhead17: haha :) Yeah that I'm sure about .. the oldest and cruftiest afaik | 19:27 |
| kim0 | koolhead17: man you should try ensemble :P We have a formula authors tutorial now Yaay https://ensemble.ubuntu.com/docs/write-formula.html | 19:28 |
| koolhead17 | i might say adious to it tomorrow after spending some more hours. there is no ubuntu community documentation 4 CFengine and Puppet :( | 19:28 |
| * koolhead17 clicks | 19:28 | |
| * kim0 joins real life .. back in an hour or two | 19:30 | |
| niemeyer | hazmat: Would you mind to lower down the mic volume a little bit? | 19:42 |
| niemeyer | bcsaller: Re. [16], on this point: | 20:48 |
| niemeyer | """ | 20:48 |
| niemeyer | While I made these changes its worth noting that they are not exactly | 20:48 |
| niemeyer | the same as a missing config.yaml means the service takes no options. | 20:48 |
| niemeyer | So, for example, file not found isn't considered an error. | 20:48 |
| niemeyer | """ | 20:48 |
| niemeyer | bcsaller: This distinction is in usage of the interface, not on the interface itself | 20:48 |
| niemeyer | bcsaller: I totally agree with your understanding of what the user should see when the file is missing, though | 20:49 |
| bcsaller | gustavo: ok | 20:49 |
| niemeyer | bcsaller: Our disagreement is just that the API of Metadata and Config should be equivalent, despite those details | 20:49 |
| niemeyer | bcsaller: re [19], in many cases the parenthesis were simply NOOP | 20:50 |
| niemeyer | bcsaller: When it's used for wrapping, there are no issues | 20:50 |
| niemeyer | bcsaller: E.g. | 20:50 |
| niemeyer | > + "%s is not a valid configuration option." % (option)) | 20:50 |
| niemeyer | bcsaller: This is a bit like saying (1) + (2), etc | 20:51 |
| bcsaller | yeah, some got moved around and then not removed after not being needed for formatting | 20:51 |
| niemeyer | bcsaller: On [22], the point raised was mostly about the ordering of arguments | 20:52 |
| bcsaller | I was explaining the history, I got your point :) | 20:52 |
| niemeyer | bcsaller: Not how regex_validator takes exactly the same arguments of match | 20:52 |
| niemeyer | bcsaller: Ah, ok, I'm the one who misunderstood then, sorry | 20:52 |
| niemeyer | bcsaller: I don't see how the change would keep the validation API, given that every other function takes a single argument and went through a different path entirely | 20:53 |
| niemeyer | bcsaller: But now that things have changed, this is a moot point anyway | 20:54 |
| bcsaller | yeah, that wasn't the plan orig :) | 20:54 |
| niemeyer | bcsaller: The API is still not matching.. not sure if I have the latest work? | 20:58 |
| bcsaller | I'll check it again, there should be one code path | 20:59 |
| niemeyer | bcsaller: It still has "optional", no parse_serialization_data, parse is taking different kinds of data, etc | 21:00 |
| niemeyer | bcsaller: http://pastebin.ubuntu.com/622012/ | 21:01 |
| niemeyer | bcsaller: This is the relevant part of MetaData | 21:01 |
| niemeyer | bcsaller: ConfigOptions is doing exactly the same thing in all of those cases. It feels like a good idea to have the same API on both. | 21:01 |
| bcsaller | I didn't know you needed that level of parity, I can work on changing it | 21:02 |
| niemeyer | bcsaller: There are two kinds of file. Both of them are within the formula. They both require the same kind of API from the application. Why would these two APIs be different? | 21:04 |
| _mup_ | ensemble/security-specification r241 committed by kapil.thangavelu@canonical.com | 21:04 |
| _mup_ | additional escalation scenarios, outline next steps broadly | 21:04 |
| bcsaller | you're right, I was focused on the wrong things | 21:04 |
| niemeyer | bcsaller: The watch_config has exactly the same issues re. exists_d than what we're discussing with jim | 21:16 |
| niemeyer | bcsaller: Let's just move it on, though | 21:16 |
| niemeyer | hazmat: One more for us to look at ^ | 21:16 |
| niemeyer | bcsaller: It's looking good.. [16] is the only mildly boring issue to look at | 21:25 |
| niemeyer | bcsaller: I've posted a few other comments in the merge proposal, mostly stylistic, though | 21:25 |
| bcsaller | ok, great | 21:25 |
| niemeyer | bcsaller: It's approved too, thanks for pushing it through | 21:25 |
| bcsaller | I'll give it another pass and then push it | 21:25 |
| niemeyer | bcsaller: Just sort that API issue first, please, and it's good to go. | 21:26 |
| bcsaller | and move the next branch into review | 21:26 |
| bcsaller | yes sir :) | 21:26 |
| bcsaller | thanks for the review | 21:26 |
| * niemeyer quickly finds a dictator's hat to wear | 21:27 | |
| niemeyer | bcsaller: np, sorry for the trouble :) | 21:27 |
| SpamapS | hmm | 21:31 |
| SpamapS | starting to package txzookeeper | 21:31 |
| SpamapS | mocker.py should be dropped and a dependency on mocker added.. | 21:32 |
| niemeyer | SpamapS: mocker was meant to be embedded in projects | 21:41 |
| niemeyer | SpamapS: So this is fine | 21:41 |
| niemeyer | SpamapS: It's not polluting the global space, and is only for testing | 21:41 |
| SpamapS | If its not generated, it will likely get rejected by an overzealous archive admin. :-/ | 21:48 |
| niemeyer | SpamapS: The mocker upstream explicitly designed mocker for it to be embedded in projects. | 21:48 |
| SpamapS | Yeah, thats a grey area. Since its only a build time thing, I'll cross my fingers. | 21:49 |
| niemeyer | SpamapS: It's used for testing, and tests shouldn't ever break if mocker changes. | 21:49 |
| niemeyer | SpamapS: It's a well considered thing in this case | 21:49 |
| SpamapS | Debian policy doesn't really take into account upstream's intentions. ;) | 21:49 |
| niemeyer | SpamapS: I was actually against even having a mocker package, but since the Ubuntu One guys (or Launchpad, maybe) wanted very much, I couldn't really see a reason to prevent it | 21:50 |
| SpamapS | Ooo | 21:50 |
| SpamapS | they changed the language | 21:50 |
| SpamapS | I digress! | 21:50 |
| SpamapS | It used to say must not | 21:50 |
| SpamapS | "Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way." | 21:50 |
| niemeyer | "explicitly intended"! | 21:51 |
| SpamapS | Yeah, that used to say must not use them, and it didn't take into account those intentions. I think. | 21:51 |
| SpamapS | That or I was just being overly excited about something silly. (latter far more likely) | 21:52 |
| niemeyer | SpamapS: I understand the perspective.. the issue in this case is that it'll be really bad if mocker changes and tests are broken because of that | 21:52 |
| niemeyer | SpamapS: Tests are supposed to verify the application.. if the test framework breaks/changes, the whole purpose of the system is gone | 21:52 |
| SpamapS | Yeah, and there's no sane reason to be using the test framework in two projects at the same time. | 21:53 |
| SpamapS | That said, the mocker.py in txzookeeper is missing a license. | 21:55 |
| SpamapS | Will consider it licensed under MIT since the setup.py licenses the whole thing as such. | 21:57 |
| hazmat | hmm.. that should get updated to the released one with license info, i might have pulled that from landscape when i was first working on txzk | 21:58 |
| hazmat | the mocker module that is | 21:59 |
| niemeyer | SpamapS: trunk actually has one | 21:59 |
| niemeyer | SpamapS: It's BSD, IIRC | 21:59 |
| SpamapS | right | 21:59 |
| SpamapS | I'm comfortable submitting it with a blanket MIT license because the BSD and MIT licenses allow re-licensing and the same basic rights. | 22:01 |
| SpamapS | If you guys update it we can change the debian/copyright file then | 22:01 |
| niemeyer | SpamapS: The license says the text should be preserved, but I won't fight over that. :-) | 22:05 |
| niemeyer | SpamapS: I assure you the upstream will never go after you on that. ;-) | 22:05 |
| SpamapS | Since the file as distributed had no such text.. we're safe. :) | 22:06 |
| hazmat | its still technically a copyright violation if that was yanked | 22:08 |
| * SpamapS decides he may as well re-read the license portion of the policy manual again to see if his memory is dead wrong on this too. :-P | 22:08 | |
| SpamapS | hazmat: I believe at the time you received the file, it had no license. ;) | 22:08 |
| hazmat | actually that's still in there | 22:08 |
| hazmat | SpamapS, i belive, your belief reflects a statement that in the scope of the multiverse, could be known as reality | 22:09 |
| hazmat | ;-) | 22:09 |
| _mup_ | ensemble/bootstrap-shutdown-environment r248 committed by kapil.thangavelu@canonical.com | 22:09 |
| _mup_ | bootstrap operates on only one environment, shutdown next. | 22:09 |
| SpamapS | I'm reading the manual because this situation has come up so many times.. it has to have a better resolution than "bug the upstream to add a copyright and license header to everything" | 22:10 |
| niemeyer | SpamapS: There isn't one, likely.. the problem is that something without a license defaults to being proprietary | 22:10 |
| hazmat | SpamapS, that's an acceptable answer afaics, i can add it in | 22:10 |
| niemeyer | Luckily, in this case, we have good access to the upstream, and nothing like that is necessary. :-) | 22:11 |
| SpamapS | "Note that under international copyright law (this applies in the United States, too), no distribution or modification of a work is allowed without an explicit notice saying so. Therefore a program without a copyright notice is copyrighted and you may not do anything to it without risking being sued! Likewise if a program has a copyright notice but no statement saying what is permitted then nothing is permitted." | 22:13 |
| SpamapS | http://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright | 22:13 |
| hazmat | there is an existing copyright notice | 22:13 |
| hazmat | at least in the mocker.py of txzk | 22:13 |
| SpamapS | explicit notice saying so.. I'd say Kapil's debian/copyright file is sufficient ;) | 22:14 |
| _mup_ | txzookeeper/mocker-license r39 committed by kapil.foss@gmail.com | 22:14 |
| _mup_ | update mocker to latest release, which includes license header | 22:14 |
| SpamapS | hazmat: copyright yes. license, no. | 22:14 |
| SpamapS | But | 22:15 |
| SpamapS | I think the debian/copyright file you put in is technically a blanket license | 22:15 |
| hazmat | niemeyer, can i get a +1 on this trivial http://pastebin.ubuntu.com/622062/ | 22:15 |
| niemeyer | hazmat: +1! | 22:16 |
| hazmat | SpamapS, its not clear how that's possible on aggregate work.. but i guess deb frowns on those | 22:16 |
| SpamapS | the question is, did you have a right to re-license Gustavo's work... the answer is of course yes, but I need to have evidence of that to put in the debian/copyright file. | 22:16 |
| niemeyer | SpamapS: I think debian/copyright is something else than what we're debating about | 22:17 |
| * SpamapS has had 2 uploads to Debian rejected for these reasons. | 22:17 | |
| niemeyer | SpamapS: If not, I'd be happy to learn | 22:17 |
| SpamapS | well there are two copyright files in the discussion | 22:17 |
| _mup_ | txzookeeper/trunk r39 committed by kapil.foss@gmail.com | 22:17 |
| _mup_ | [trivial] merge mocker-license which updates mocker to 1.1 which includes a license header for packaging [r=niemeyer] | 22:17 |
| hazmat | SpamapS, hopefully that helps | 22:17 |
| niemeyer | SpamapS: Isn't debian/copyright the _package_ copyright (debian/*)? | 22:17 |
| SpamapS | there's the one Kapil put in txzookeeper's trunk, which serves as a blanket MIT license for the rest of the code... | 22:17 |
| SpamapS | and then there's the one I'm tidying up for upload to Debian | 22:18 |
| SpamapS | The former is just a reference work at this point. The latter is used by the Debian and Ubuntu projects as an assurance to their users that they can in fact use the software. | 22:19 |
| hazmat | off to dinner, back in a bit | 22:19 |
| SpamapS | hazmat: thanks, that may be enough, I'm going to ask around a bit | 22:19 |
| SpamapS | I think I've spent way too much time on this, since the new trunk has the licensed code.. the matter is pretty much resolved | 22:20 |
| niemeyer | jimbaker`: expose-hook-commands looks very nice and tiny, thanks | 22:22 |
| SpamapS | ./txzookeeper/tests/mocker.py: BSD (3 clause) | 22:22 |
| niemeyer | tidy | 22:22 |
| SpamapS | yay | 22:22 |
| jimbaker` | niemeyer, thanks | 22:22 |
| SpamapS | Can we make a tarball release of txzookeeper? | 22:56 |
| SpamapS | actually | 23:01 |
| SpamapS | it seems that packaging from VCS is totally legit | 23:02 |
| SpamapS | w00t | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!