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