13:03:19 <andreasn> #startmeeting
13:03:19 <zodbot> Meeting started Mon Oct 19 13:03:19 2015 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:03:23 <stefw> elevator music
13:03:25 <andreasn> .hello andreasn
13:03:26 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:03:28 <stefw> .hello stefw
13:03:31 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
13:03:35 <dperpeet> .hello dperpeet
13:03:36 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:04:07 <mvollmer> .hello mvo
13:04:08 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:04:19 <mvollmer> andreasn, thanks for chairing
13:04:28 <andreasn> #topic agenda
13:05:02 <stefw> * "Fully functional distros" ... aka Debian packaging ... aka "is this only a Red Hat project"
13:05:19 <andreasn> good topic
13:06:39 <andreasn> that's all we have?
13:06:40 <dperpeet> * use of priority label on github
13:08:10 <andreasn> sounds good. We also have open floor if anyone can think of something during the way
13:08:19 <andreasn> #topic Fully functional distros
13:08:38 <stefw> So we've worked hard to make Cockpit the UI for Fedora Server
13:08:41 <stefw> and now it's also built for RHEL
13:08:49 <stefw> and we test well on those distros
13:08:55 <stefw> most people who contribute to Cockpit are hired by Red Hat
13:08:59 <stefw> but it would be nice to go beyond that
13:09:03 <andreasn> yup
13:09:10 <stefw> or at least not shut people out who want to make it go beyond that
13:09:12 <dperpeet> definitely!
13:09:37 <stefw> some of the obstacles are presented here:
13:09:37 <stefw> https://github.com/cockpit-project/cockpit/issues/2912
13:10:00 <stefw> and there are some allusions to 'first class distro'
13:10:04 <stefw> i don't know if that's a good name
13:10:10 <andreasn> the arch repo is on 0.79 https://aur.archlinux.org/packages/cockpit/
13:10:11 <stefw> but basically a list of operating systems on which Cockpit runs well
13:10:18 <stefw> and instructions for how to get them to that point
13:10:54 <stefw> it's great that Arch is keeping up with packaging
13:11:24 <stefw> but do we want to open up the playing field for testing and so on?
13:11:27 <dperpeet> maybe it would be viable to support any distro as long as there is at least one person willing to put their name on it as the maintainer
13:11:40 <stefw> right, it would have to be contributor driven
13:11:50 <stefw> so someone would need to put in the effort
13:12:03 <stefw> but i would like to see if we can prepare the infrastructure so that people can join in and be effective maintainers
13:12:18 <mvollmer> i think we can justify some of our time on kickstarting, say, Debian.
13:12:21 <andreasn> so for arch, do you see that as being one of the automated test systems (provided the maintainer gets involved)
13:12:27 <andreasn> the maintainer, a maintainer
13:12:36 <stefw> mvollmer, yes, i was wondering about that
13:12:49 <dperpeet> I think one big step is that we can get the tests working from anywhere and use the results
13:12:58 <stefw> as a first step actually doing some Debian work ourselves would be part of making Cockpit well rounded
13:13:06 <mvollmer> yeah
13:13:14 <stefw> as far as testing, having distributed tests becomes important
13:13:14 <stefw> so they can run on other people's hardware
13:13:17 <stefw> and with other maintainers
13:13:45 <stefw> at some point if a given distro (this is pure theory) is testable and deliverable weekly
13:14:03 <stefw> then we could even add it to the github status for integration tests
13:14:08 <stefw> the reason i say this is pure theory
13:14:21 <dperpeet> we have to think this through a bit: imagine a list of distros with their maintainers and intersect this with maintainers for specific parts of cockpit
13:14:22 <stefw> is because fedora and RHEL tests fall over more than 80% of the time right now
13:15:04 <dperpeet> we could define a set of "core" tests
13:15:29 <dperpeet> say you want to maintain cockpit, but not with openshift and ipa for your distro
13:15:39 <stefw> that's easy to do by modifying the tests slightly
13:15:44 <stefw> and skipping them
13:15:52 <dperpeet> true
13:16:15 <stefw> anyway, so i guess this is very broad
13:16:22 <stefw> we need to bring this back to concrete next steps
13:16:38 <dperpeet> are the people who currently already port cockpit to their distro in on https://github.com/cockpit-project/cockpit/issues/2912 ?
13:17:03 <stefw> mvollmer, if we did work on Debian how would it be delivered?
13:17:11 <mvollmer> good question
13:17:52 <mvollmer> ideally we find a debian person who wants to be maintainer
13:17:55 <dperpeet> I think the most obvious place we need to start changing is http://cockpit-project.org/running.html
13:18:19 <mvollmer> and we work on getting cockpit into a good enough shape and into continous testing
13:18:31 <stefw> and then call for an actual package maintainer?
13:18:34 <stefw> for Debian?
13:18:41 <stefw> i think if we did the ground work of getting it running through the tests
13:18:41 <dperpeet> yeah
13:18:43 <mvollmer> and then we let go and the maintainer continues
13:18:51 <stefw> right
13:19:05 <dperpeet> I agree with the ground work
13:19:23 <dperpeet> leave packaging + distributing to someone else
13:19:30 <stefw> well the thing is ...
13:19:33 <mvollmer> debian has this nice testing framework that martin pitt works on
13:19:34 <stefw> we're moving towards continuous delivery
13:19:54 <stefw> mvollmer, so does OpenSUSE ... and everyone
13:19:58 <dperpeet> maybe we should start a wiki page on what maintaining a distro for cockpit means
13:20:03 <stefw> dperpeet, yes ++
13:20:16 <dperpeet> right now this is spread out a bit
13:20:22 <dperpeet> with most parts being done by stefw and pedroigor
13:20:25 <dperpeet> petervo, sorry
13:20:39 <stefw> so one concrete question?
13:20:44 <stefw> does this mean we move away from mock
13:20:53 <stefw> and into building cockpit inside of one of our cockpit flavor vms?
13:20:59 <stefw> because that would generalize to different operating systems
13:21:02 <stefw> whereas mock won
13:21:03 <stefw> t
13:21:29 <dperpeet> I think that would be good
13:21:48 <dperpeet> it's also a direction jscotka already proposed moving into when he worked on https://github.com/cockpit-project/cockpit/blob/master/test-avocado/compiletest.sh
13:21:54 <stefw> we could, for example, have --quick use rpmbuild directly
13:21:54 <stefw> and build on the host
13:21:54 <stefw> for people who want to run ./testsuite-prepare quickly
13:22:06 <stefw> dperpeet, yes that's an interesting correlation
13:22:24 <dperpeet> just getting cockpit to compile is a good initial test for a distro's viability
13:22:35 <dperpeet> to get all our dependencies in order
13:22:47 <dperpeet> it might not be a bad thing to have this as an explicit test
13:22:48 <stefw> right, and doubly so getting it to compile as part of our cockpit infrastructure
13:22:56 <dperpeet> and the logs are in the same place then
13:22:59 <dperpeet> not in a separate mock place
13:23:03 <dperpeet> in case something goes wrong
13:23:24 <stefw> one other concrete thing
13:23:35 <stefw> it has been mentained that teh copyright notice here is offputting to contributors:
13:23:40 <jscotka> dperpeet, yea, it is long discussion :-) If I undersnad correctly you mentioned to compile it independently on rpm?
13:23:44 <stefw> http://cockpit-project.org/
13:23:56 <stefw> jscotka, yes, we would continue to use rpmbuild
13:23:57 <stefw> just inside the vm
13:24:14 <sgallagh> stefw: What part of it is offputting?
13:24:23 <stefw> https://github.com/cockpit-project/cockpit/issues/2912
13:24:31 <andreasn> I'm happy to change the copyright info, not sure what's recommended though
13:24:49 <sgallagh> andreasn: Oh, that it's copyright Red Hat?
13:24:49 <jscotka> stefw, yes, I think that it is very useful, because I can imagine, that lots of distros with systemd can use cockpit, and would be nice to do is as easy as possible
13:24:53 <sgallagh> I don't think that's actually true.
13:25:19 <andreasn> perhaps not. I just put it there when we launched it
13:25:35 <andreasn> should it say something else, or just be removed?
13:25:45 <stefw> i think it could be removed
13:26:04 <sgallagh> I think it should say "Copyright Cockpit Contributors"
13:26:12 <dperpeet> sgallagh +1
13:26:12 <stefw> sounsd good to me
13:26:16 <andreasn> sure
13:26:19 <andreasn> I'll change it
13:26:26 <dperpeet> do we have a statement on project governance?
13:26:52 <stefw> no we don't ...
13:27:01 <dperpeet> something like http://libvirt.org/governance.html
13:27:03 <stefw> i wouldn't be against one ... but i think the first step is to remove any barriers to contributoion
13:27:11 <stefw> and as we get bigger add things like that
13:27:23 <sgallagh> Yeah, that's overkill for most projects.
13:27:30 <dperpeet> I'm just saying this is something we should keep in mind
13:27:48 <stefw> sure, when the need arises
13:27:54 <sgallagh> A simple statement like "Cockpit is a meritocracy: prove you are reliable and you'll earn commit privileges." is probably enough unless it grows too large
13:28:15 <stefw> yup
13:28:21 <dperpeet> yeah, but something along those lines needs to be visible
13:28:24 <stefw> dperpeet, something like that could go on teh contributors page
13:28:30 <stefw> well lets make the Contributors page more visible
13:28:31 <dperpeet> I can add that
13:28:43 <sgallagh> stefw: +1
13:28:58 <stefw> andreasn, where could we have a link to our contributors wiki page?
13:29:03 <stefw> because over time that could grow into sections
13:29:08 <stefw> 1. Contribute to cockpit code
13:29:15 <stefw> 2. Contribute to packaging cockpit for your OS
13:29:21 <dperpeet> how about on http://cockpit-project.org/: try it out, get the source, contribute [link to wiki]
13:29:36 <github> [cockpit] mvollmer opened pull request #2977: storaged: Move "Format" button into Content panel (master...storaged-easier-partition-table) http://git.io/vCj4R
13:29:41 <andreasn> sure
13:29:41 <stefw> for reference, this is the current page: https://github.com/cockpit-project/cockpit/wiki/Contributing
13:29:48 <stefw> dperpeet, yes, i like that
13:29:49 <dperpeet> to clarify that everyone is welcome to pitch in
13:30:17 <sgallagh> Keep issue-reporting on the front page though
13:30:27 <sgallagh> When someone has a problem, they don't want to dig for it
13:31:00 <andreasn> https://github.com/cockpit-project/cockpit-project.github.io/issues/31
13:31:21 <dperpeet> andreasn, ohhh... close the two digit issues!
13:31:54 <dperpeet> (I know there aren't that many issues there yet)
13:33:26 <stefw> so lets make the changes to the website
13:33:29 <stefw> and look into Debian packaging
13:33:52 <andreasn> I wonder if we could add a "Your distro here" on http://cockpit-project.org/running.html
13:33:59 <stefw> i think that drawing up a big policy on "steps to package cockpit on your operating system"
13:34:02 <stefw> and instructions
13:34:03 <mvollmer> stefw, are you thinking of having a debian/ directory in our sources?
13:34:08 <stefw> would be premature if we haven't even done it for Debian
13:34:12 <andreasn> with a small text saying "if you want to see cockpit for your distro, do this"
13:34:19 <stefw> mvollmer, the policy has been that
13:34:36 <stefw> we include distro specific packaging (like spec files) if it is being used to run tests
13:34:42 <mvollmer> yep
13:34:54 <stefw> this is a natural way to determine which distros are first class upstream, continuously integrated, continously delivered
13:34:55 <mvollmer> so we get some testing going as the first step
13:34:58 <mvollmer> sounds good
13:35:04 <stefw> if that absolutely requires a debian/ directory that's fine
13:35:08 <stefw> but ideally we could make it tools/debian/
13:35:19 <mvollmer> yes
13:35:20 <stefw> and rewrite while building appropriate tarballs, source files
13:35:29 <dperpeet> we should make a note of this intention in our next release notes, stefw
13:35:31 <mvollmer> yes, should be doable
13:35:49 <stefw> lets make a baby step before we make a big deal about it
13:35:54 <dperpeet> maybe we can get some people onboard who've been packaging cockpit for debian already
13:35:59 <stefw> even running one test on debian as part of our integration tests would be enough, i think
13:36:03 <dperpeet> ok
13:36:07 <stefw> who has been packaging cockpit for debian?
13:36:13 <stefw> if there's anyone we should definitely reach out
13:36:19 <stefw> there have been PPA's but they're ancient, and not for debian
13:36:22 <dperpeet> ah ok
13:36:27 <dperpeet> I thought there might have been
13:36:34 <dperpeet> andreasn, https://github.com/cockpit-project/cockpit/wiki/About we need an icon for trello here
13:36:44 <stefw> by tackling debian we basically ensure cockpit works on "the other big half" of linux distros
13:36:47 <andreasn> sure, I'll fix that
13:37:01 <mvollmer> https://github.com/cockpit-project/cockpit/issues/2051
13:37:02 <dperpeet> andreasn, I just added that link :)
13:37:07 <stefw> i don't think that after doing debian we should then work on each distro in turn
13:37:12 <mvollmer> ^^ some guy trying to build cockpit in jessie
13:37:17 <stefw> at that point we'll be ready to have others do the work
13:37:49 <dperpeet> I agree
13:38:22 <mvollmer> i would volunteer for debian work if we decide this is the right time
13:38:30 <dperpeet> otherwise integration tests will eat up our time
13:39:40 <dperpeet> so I think the consensus is that we do this for debian
13:39:49 <dperpeet> fix the issues we find along the way
13:39:54 <stefw> yeah
13:39:59 <dperpeet> and then write up what it means to maintain a distro?
13:40:01 <dperpeet> for cockpit
13:40:06 <stefw> yup
13:40:32 <andreasn> so seems there is some action items
13:40:36 <andreasn> next topic?
13:40:55 <dperpeet> I'm fine with mvollmer looking into this from a practical side :)
13:41:13 <mvollmer> okay, I'll put it on the lists
13:41:44 <dperpeet> thanks!
13:42:09 <andreasn> #topic Use of priority label on github
13:42:33 <dperpeet> our priority label "sort of" works now
13:42:52 <dperpeet> but mvollmer correctly observed that we should coordinate a bit on how to use this
13:43:13 <mvollmer> i think adhoc is fine
13:43:28 <stefw> i think so too ... lets see how it works first
13:43:30 <dperpeet> I'd be happy with the guideline that it'd be nice for someone besides the author to add it
13:43:30 <mvollmer> before a release to mark what should go in
13:43:44 <mvollmer> stuff that helps with making other PRs pass
13:43:45 <dperpeet> but no strict rules
13:43:51 <stefw> dperpeet, nah, i think that's not helpful
13:43:55 <stefw> because we're all fixing each other's tests
13:44:00 <stefw> and the races we've all introduced
13:44:01 <dperpeet> fair enough
13:44:03 <stefw> and those have to be priority
13:44:16 <stefw> i've been marking pretty much any test fix as priority
13:44:23 <stefw> so exactly what mvollmer said
13:44:26 <dperpeet> ok
13:44:35 <dperpeet> and maybe also stuff that's been forgotten
13:44:37 <dperpeet> :)
13:45:04 <dperpeet> like when all tests are already green
13:45:12 <dperpeet> but nobody got around to merging
13:45:27 <dperpeet> note that this won't affect other tests negatively anyway
13:45:41 <dperpeet> due to the slight priority gain via the label
13:45:47 <dperpeet> ok, end of topic
13:46:07 <andreasn> #topic Open Floor
13:46:43 <mvollmer> where should the NTP item be on trello now?
13:46:52 <stefw> once it's merged it goes into Done
13:46:59 <mvollmer> is it in "Implementation" while the PR is open?
13:47:03 <stefw> yup
13:47:09 <mvollmer> or in "Ready"
13:47:21 <stefw> ready is ready for delivery
13:47:31 <mvollmer> like, in master but not tagged yet?
13:47:43 <stefw> yup
13:47:47 <stefw> i've cleaned up Ready
13:47:52 <stefw> forgot to do that last week
13:47:52 <mvollmer> oh, trello moves
13:48:01 <stefw> no, we do it manually
13:48:05 <mvollmer> okay
13:48:43 <stefw> essentially the Done cards answer the question:
13:48:44 <mvollmer> the debian work would start out in "Research/...", right?
13:48:50 <stefw> "What release did feature Y appear in"
13:48:52 <stefw> mvollmer, yup
13:48:54 <dperpeet> I'd say so
13:48:57 <mvollmer> okay
13:49:31 <mvollmer> so I am going to work on my bug/issue backlog next, and the Debian stuff.
13:49:41 <mvollmer> or should I do SOS first?
13:49:56 <stefw> SOS would certainly be nice
13:50:07 <mvollmer> yeah, "looks easy". :-)
13:50:09 <stefw> lets talk about this later and figure that out ...
13:50:15 <stefw> mvollmer, heh yes as NTP did
13:50:17 <mvollmer> I will do that before Debian then
13:50:23 <andreasn> hehe
13:50:30 <mvollmer> .-)
13:50:51 * mvollmer keep typing pirate smilies for some reason.. hmm.
13:51:09 <dperpeet> heh '-)
13:51:22 <andreasn> all right, that's all, unless someone has anything else
13:51:32 <andreasn> something else
13:52:17 <sgallagh> I have an item for open floor
13:52:33 <sgallagh> I was thinking this morning about discoverability of Cockpit.
13:53:00 <sgallagh> One of the common (we expect) use-cases is to have a bastion host that you would connect to and manage the others, yes?
13:53:23 <sgallagh> Perhaps its time to consider defining a well-known SRV record for that bastion host.
13:53:39 <andreasn> SRV?
13:53:54 <sgallagh> So when you log into any Cockpit service on the network, you will always have the option to add the bastion to the dashboard
13:54:01 <sgallagh> andreasn: It's a DNS record type.
13:54:15 <sgallagh> It's used mostly for auto-discovery
13:54:30 <sgallagh> For example the ._ldap._tcp SRV record is how you autodiscover LDAP servers
13:54:35 <stefw> sgallagh, cockpit dashboard is one hop
13:54:49 <stefw> so by adding a bastion host to a dashboard you don't somehow inherit its dashboard
13:55:00 <stefw> Or am i completely misunderstanding this?
13:55:05 <mvollmer> sgallagh, why would the bastion host be on the dashboard? it's the one hosting the dashboard, no?
13:55:14 <sgallagh> You're not, but I mixed two thoughts at the same time and got the wrong result
13:55:52 <mvollmer> we should work on auto discovery
13:55:55 <andreasn> where is the SRV record hosted?
13:56:12 <sgallagh> Perhaps if such a SRV record existed, we could just do a 403 to forward connections to it instead?
13:56:20 <sgallagh> andreasn: In the DNS server
13:56:25 <andreasn> ah, ok
13:56:31 <sgallagh> Such as FreeIPA, AD, BIND9, etc.
13:56:58 <stefw> i'm still not understanding the use case
13:57:09 <stefw> why would cockpit be accessible on port 9090 on all the machines
13:57:13 <stefw> if yo uwant ot use a bastion host
13:57:29 <sgallagh> stefw: Maybe "bastion" was the wrong term
13:57:30 <stefw> in those cases cockpit-ws is accessible on port 9090 on one machine
13:57:32 <stefw> and it connects to the others
13:57:41 <sgallagh> I'm thinking in terms of a "primary dashboard", really
13:58:17 <sgallagh> One that you set up once to have easy access to the others.
13:58:27 <dperpeet> sgallagh, like a good reminder of which host you set up to do that? =)
13:59:04 <stefw> bookmarks?
13:59:05 <sgallagh> Yeah, although I suppose one might just handle that by creating a CNAME record for dashboard.example.com or something...
13:59:18 <stefw> we do have this card: https://trello.com/c/VcxIAlDi/144-standard-way-to-track-if-another-management-system-is-controlling-the-host
13:59:23 <stefw> which should show something on the server page
13:59:24 <stefw> like
13:59:26 <dperpeet> I don't see this being something that's really necessary inside cockpit
13:59:29 <stefw> "this server is being managed from Satellite here"
13:59:34 <stefw> in theory if the implementation was general
13:59:39 <sgallagh> hmm
13:59:43 <stefw> it could display a similar message for Cockpit
13:59:49 <stefw> but we'd have to really think about that carefully
14:00:09 <dperpeet> stefw, I thought about something like that, but like you said: the implications...
14:00:23 <stefw> yup
14:00:37 <dperpeet> cockpit is very url driven
14:00:53 <dperpeet> so bookmarks are indeed a good way to reference it
14:01:19 <stefw> yes, i would tend to agree
14:01:39 <dperpeet> that aside, discovering other hosts in the network with cockpit exposed might be nice
14:01:58 <dperpeet> "alternate hosts" on the login page
14:02:03 <stefw> also scary
14:02:04 <dperpeet> or even in cockpit, when adding another host
14:02:07 <sgallagh> dperpeet: Well, the suggestion we came up with last week at Server SIG was to use the FreeIPA JSON API when connected to such a domain
14:02:18 <sgallagh> Because it already has a list of every other machine in the domain and it's easily accessible :)
14:02:25 <stefw> right, that's a good idea
14:02:33 <stefw> needs the designs to be adapted
14:02:33 <stefw> but we can do that
14:02:36 <andreasn> oh, so showing all the other machines in the domain?
14:02:44 <sgallagh> andreasn: Showing and/or searching, yes
14:02:47 <dperpeet> stefw, true: a system that connects to others without explicitly telling it to isn't always desired
14:03:37 <sgallagh> such searches can also be limited to hostgroups as well.
14:03:51 <sgallagh> (So, "Connect me to all machines in this hostgroup" is a pattern that might be handy)
14:04:05 <dperpeet> that's a good use case I think
14:04:09 <stefw> yup
14:05:01 <andreasn> can we figure out what machines in a domain has cockpit and not?
14:05:26 <andreasn> I have some laptops in my domain
14:05:32 <andreasn> and those don't have cockpit on them
14:06:20 <sgallagh> andreasn: The easiest approach would probably be the "Ask forgiveness instead of permission" pattern
14:06:28 <andreasn> right
14:07:52 * mvollmer has to leave
14:08:09 <andreasn> yeah, I think we're done
14:08:13 <andreasn> sounds good?
14:08:57 <andreasn> sounds like it
14:09:02 <andreasn> #endmeeting