13:02:41 <stefw> #startmeeting 13:02:41 <zodbot> Meeting started Mon Aug 24 13:02:41 2015 UTC. The chair is stefw. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:47 <mvollmer> .hello mvo 13:02:47 <stefw> #topic Agenda 13:02:47 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 13:02:58 <stefw> .hello stefw 13:02:59 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com> 13:03:03 <mvollmer> * travis/semaphore/... 13:03:08 <stefw> * Continuous delivery 13:03:16 <mvollmer> * generic service api 13:03:18 <stefw> * SSH agent code 13:03:24 <stefw> * Accessing non-localhost from bridge 13:03:54 <petervo> * travis ci 13:05:12 <stefw> #topic travis/semaphore/... 13:05:26 <stefw> gentlemen start your engines 13:05:31 <mvollmer> right, i have some news about the travis bug 13:05:46 * stefw Is so happy that Travis is open source 13:05:47 <mvollmer> big/fast writes to stdout can cause EAGAIN 13:06:07 <mvollmer> and we seem to just at the edge of what counts as "big" 13:06:38 <mvollmer> make distclean writes very long commands to stdout, and if we add more files to our non-recursive Makefiles, we go over the limit 13:06:40 <mvollmer> apparently 13:06:54 <mvollmer> and make/anyone doesn't handle EAGAIN 13:07:16 <mvollmer> so I made a small workaround that writes more carefully and we pipe through that 13:07:28 <mvollmer> PR is in the making 13:07:50 <petervo> nice 13:07:54 <mvollmer> but I am not saying that we shouldn't switch to semaphore 13:08:06 <mvollmer> i just have character flaw that I can't let go of a bug 13:08:36 <mvollmer> i think the pros are still very strong 13:08:48 <stefw> but is semaphore open source? 13:08:54 <mvollmer> idk 13:09:00 <petervo> don't think so 13:09:06 <stefw> badum tsch 13:09:25 <mvollmer> yeah 13:09:35 <mvollmer> should we also switch to gitlab? :-) 13:09:44 <stefw> well .... 13:09:46 <stefw> the thing is 13:09:52 * stefw could talk about this for hours 13:09:58 <stefw> github is about the social stuff 13:10:03 <stefw> and it doesn't matter if github is open source 13:10:06 <stefw> it'll never be 'free software' 13:10:15 <stefw> in that you can't modify it, even if you had the source code 13:10:33 <stefw> SaaS + Social needs a new Richard Stallman 13:10:39 <stefw> or some similar revolution 13:10:49 <stefw> because it's just a impass 13:10:59 <mvollmer> richard care about the code you run in your browser 13:11:12 <stefw> you can't have social + free software + the current web architecture 13:11:18 <stefw> mvollmer, yes, that means reinventing the web ... basically 13:11:20 <stefw> so long story short 13:11:23 <mvollmer> but what runs on the server, well, that's a different thing. 13:11:30 <stefw> if we want the social aspects of GitHub 13:11:44 <stefw> we can't currently (given the way the web is) anything approaching 'free software' 13:11:59 <fche2> affero-gpl ftw 13:12:16 <stefw> but in general we should support open source services 13:12:22 <stefw> and Travis has no social element 13:12:33 <stefw> therefore it's replaceable ... and doesn't suffer from these issues 13:12:50 <stefw> it is capable of, true open source, free software whatever ... so we should support it 13:13:06 <mvollmer> suport == using their resources without paying :-) 13:13:13 <stefw> no, help them fix this bug 13:13:18 <mvollmer> but, yes, I agree. 13:13:28 <mvollmer> about everything, actually. 13:13:47 <mvollmer> i can tolerate github as long as the API is there 13:14:02 <mvollmer> and I could in theory write my own client. 13:14:32 <stefw> anyway, back to the issue 13:14:36 <mvollmer> and the social aspect is the reason why we went there in the first place 13:14:38 <mvollmer> yep 13:14:41 <stefw> i guess we should file a bug on travis? 13:14:49 * stefw tries to figure out which component 13:14:50 <mvollmer> yes 13:15:04 <mvollmer> we ca file it against the top-level, I guess 13:15:07 <mvollmer> travis-vi 13:15:12 <mvollmer> *travis-ci 13:15:19 <mvollmer> travis-emacs 13:15:23 <stefw> sounds good 13:15:32 <mvollmer> I will do that 13:15:39 <stefw> #info mvollmer will file a bug on travis, and try to help find the source of the issue 13:16:08 <mvollmer> #info mvollmer will also install a workaround for us 13:17:03 <mvollmer> okay, anything about semaphore? 13:17:13 <mvollmer> should we wait for how well the workaround works? 13:17:37 <petervo> i'll keep my account around for now 13:17:41 <mvollmer> or is it decided that we stay with travis? 13:17:51 <petervo> just because the version we need is invite only 13:18:03 <petervo> once we have travis working i'll delete it 13:18:06 <mvollmer> ohh, that's a con. 13:18:21 <mvollmer> okay, we all owe petervo some beer for doing the work 13:18:22 <petervo> yeah it was in my list 13:18:31 <petervo> the inotify thing 13:19:42 <petervo> next topic? 13:19:46 <mvollmer> i am not sure I understand 13:20:18 <mvollmer> yes, next topic. 13:20:23 <stefw> yes thanks petervo, for looking into that ... if we do hit a wall with Travis, it's good to know we can switch easily 13:20:32 <stefw> #topic Continuous Delivery 13:20:44 <stefw> so now that our continuous integration has been going so well (ha ha) 13:21:07 <stefw> I've gotten tired of doing the entire tedious and error prone release dance over and over again ... as I imagine so has Peter 13:21:19 <stefw> I've posted to cockpit-devel mailing list some goals for where we want to be on continuous delivery 13:21:21 <stefw> the upshot is: 13:21:26 <stefw> a) tag a release 13:21:48 <stefw> b) tag becomes a release goes into fedora (specific versions), docker container, github releases page, copr 13:21:51 <stefw> all automatically 13:21:56 <stefw> ... and then eventually 13:22:12 <stefw> c) the release is tested with our integration tests again ... if passes in Fedora, promoted into an update and pushed out 13:22:26 <stefw> the last release 0.72 was done purely with scripts 13:22:38 <stefw> everything from %changelog updates, to koji git commits, and builds, to copr 13:22:43 <stefw> to github release uploaded etc... 13:22:46 <stefw> was all from a script 13:22:52 <stefw> so we can polish those scripts a bit for a while 13:22:58 <stefw> before we actually start triggering them automatically 13:23:16 <github> [cockpit] mvollmer opened pull request #2611: travis: Write build output carefully to stdout. (master...travis-careful-cat) http://git.io/vsPjZ 13:24:01 <mvollmer> nice 13:24:11 <stefw> so anyone against this in principle? 13:24:16 <mvollmer> also one of those things that "should exist already", no? 13:24:27 <mvollmer> no, sounds very good 13:24:30 <stefw> well it's hopelessly project and destination specific 13:24:36 <stefw> i'm using mainly written command line tools 13:24:39 <stefw> and tying them together 13:24:46 <stefw> one cool part was that these all run as scripts 13:24:56 <stefw> and before commiting their changes, each script SIGSTOPs itself 13:25:04 <stefw> the runner then checks if everything got to that point 13:25:09 <stefw> and if so, resumes the scripts one by one 13:25:17 <stefw> so they complete their actual non-draft or scratch change 13:25:47 <mvollmer> cool :) 13:26:04 <stefw> alright, next topic? 13:26:15 <stefw> #topic Generic Service API 13:26:19 <mvollmer> ok 13:26:41 <mvollmer> so we have two places now that want to mess with services 13:26:51 <mvollmer> multipath wants to switch on the daemon 13:27:04 <mvollmer> and we want to switch on/off pmlogger 13:27:21 <stefw> also docker, right? 13:27:27 <mvollmer> yes, true! 13:27:35 <mvollmer> three places 13:27:40 <mvollmer> nobody expects docker 13:27:43 <mvollmer> sorry 13:27:56 <stefw> :) 13:27:56 <mvollmer> so, using systemd directly is tricky 13:28:19 <mvollmer> so now I have wrapped it as "system/service" 13:28:28 <stefw> seems like a good idea 13:28:40 <mvollmer> and then I went further and tried to make it a generic API 13:28:46 <mvollmer> that also works for sysvinit, say 13:28:54 <stefw> and how would it know how to map names? 13:28:57 <stefw> of services? 13:28:59 <mvollmer> but stefw was right: this is tricky 13:29:19 <mvollmer> i don't even know what "enabled" should mean exactly 13:29:36 <mvollmer> you would have to know the names 13:29:49 <mvollmer> which are hopefully the same... 13:30:03 <stefw> seems like it's premature to generalize this no? 13:30:07 <mvollmer> but yes, this is trying to abstract things that don't need sbtracting right now 13:30:10 <mvollmer> very dangerous 13:30:20 <mvollmer> I agree 13:30:30 <mvollmer> still, it is good for our own use 13:30:48 <stefw> yes i just think we shouldn't expect it to be stable 13:30:52 <mvollmer> yep 13:30:54 <stefw> if we don't have a second init system that we support, yet 13:31:11 <mvollmer> yes, it would be a solution in search of a problem 13:31:36 <mvollmer> so I'll rename things and reword the docs 13:32:20 <mvollmer> eot? 13:32:23 <stefw> #info We won't imagine the general service API is stable yet 13:32:37 <stefw> #topic SSH agent code 13:32:46 <stefw> I've done some more review of the SSH code for the PAM module 13:32:54 <stefw> petervo has done really nice work here 13:33:02 <stefw> as I discussed with Peter, we've renamed this to be clearer 13:33:05 <stefw> it's called pam_ssh_add.so 13:33:08 <stefw> to be clear that's what it does 13:33:20 <stefw> it adds keys during the pam cofrumblence 13:33:31 <stefw> well ssh keys 13:33:33 <stefw> it adds them to an agent 13:33:41 <stefw> if the agent isn't running, it starts the agent 13:34:43 <stefw> the selinux issues are kind of ugly 13:34:54 <stefw> because selinux refuses to let us launch the ssh-agent after it has set up the correct context 13:35:04 <stefw> and therefore even with our workaround the ssh-agent is started with the wrong context 13:35:26 <petervo> should we break down and just use sh? 13:35:30 <stefw> yup 13:35:46 <petervo> ok 13:35:46 <stefw> says something when /bin/sh is our tool against the mighty selinux 13:36:03 <stefw> anything else on this petervo? 13:36:07 <stefw> i think with that resolved, we'd be ready to merge 13:36:13 <petervo> do we want to rename retest? 13:36:21 <petervo> if we are sharing it? 13:36:27 <stefw> if you want 13:36:30 <stefw> i don't care either way 13:36:43 <petervo> ok, i won't either 13:37:04 <petervo> i'll bring in your changes and update the PR 13:37:59 <stefw> cool 13:38:09 <stefw> #topic Accessing non-localhost from bridge 13:38:16 <stefw> Soooo heads up and food for thought 13:38:26 <stefw> usually cockpit only accesses local services 13:38:31 <stefw> and we get to other machines via SSH 13:38:39 <stefw> that means when doing TCP, we connect to localhost 13:38:47 <stefw> so far this has served us well 13:38:53 <stefw> however with more and more thingys in containers 13:39:12 <stefw> and also with openshift listening on specific addresses (even though they are local) 13:39:23 <stefw> we now have the need to have bridge connect to specific addresses 13:39:43 <stefw> which means, in theory at least, connections from the machine could leave the local machine (given the right options to the channel) 13:39:48 <stefw> does anyone have a problem with this? 13:40:13 <stefw> at a very minumum, we need to be on the lookout for assumptions that assumed only local connections would be made 13:40:19 <stefw> i tightened up the TLS validation because of this. 13:40:44 <mvollmer> no problems here 13:41:14 <mvollmer> we have cockpit.spawn, which can do everything anyway 13:41:23 <stefw> true 13:41:47 <petervo> we just need to make sure to look for code confusing the "host" and "address" options 13:41:59 <stefw> #topic Code to access non-local addresses from TCP channels are merged into master 13:42:04 * stefw wishes that host had been called machine 13:42:08 <stefw> but it's too late for that 13:43:45 <stefw> alrighty 13:43:54 <stefw> #topic Open Floor 13:44:18 <mvollmer> phantomjs in mock 13:44:45 <mvollmer> or more generally, should we try not to skip tests in mock? 13:44:45 <stefw> That's not going to work for Brew or Koji builds 13:44:59 <mvollmer> right 13:45:09 <stefw> well, even more generally, we can't make mock test everything right? 13:45:13 <stefw> so the question is where do we draw the line. 13:45:17 <mvollmer> and we have "make check" in cockpit.spec so that brew and koji do at least some testing, right? 13:45:53 <mvollmer> we rely on travis to run make check and valgrind and make distcheck, right? 13:46:09 <stefw> that was my assumption 13:46:15 <stefw> i wanted 'make check' in the cockpit.spec 13:46:16 <stefw> because 13:46:19 <stefw> a) everyone says to do it 13:46:29 <stefw> b) having continous delivery without it would be silly 13:47:07 <stefw> so the idea being that building cockpit runs the tests 13:47:14 <stefw> on the given operating system where we're building 13:47:20 <stefw> but since these operating systems don't have phantomjs 13:47:29 <stefw> and we have no way to bring it into the build system there (such as Koji) 13:47:44 <stefw> i think realistically this doesn't fit under the goals i had in mind when i added 'make check' to cockpit.spec 13:47:53 <stefw> but perhaps we have different goals for that line? 13:48:48 <mvollmer> if we use it as an alternative to travis, then we would have different goals 13:49:00 <stefw> true 13:49:06 <stefw> but then we would need to cram everything in there 13:49:10 <mvollmer> but if continue to use travis, then it can remain "easy" 13:49:12 <stefw> including 'make distcheck' and 'make check-memory' 13:49:17 <mvollmer> yes 13:49:19 <stefw> and somehow enable the root tests 13:49:25 <mvollmer> yep 13:49:37 <mvollmer> i actually tried that... 13:49:41 <mvollmer> :-) 13:50:07 <mvollmer> but I am happy as things are 13:50:20 <mvollmer> we might safe time by _not_ running make check in hubbot 13:50:28 <stefw> yes, you can do --quick 13:50:34 <mvollmer> ahh, ok. 13:50:36 <stefw> if we decide to do that 13:50:55 <stefw> tools/make-rpms --quick 13:51:57 <mvollmer> i have no strong opinion 13:52:38 <stefw> well lets let more dust settle 13:52:43 <stefw> and then make the next round of testing changes once it does 13:52:50 <mvollmer> yeah 13:54:14 <stefw> #endmeeting