14:01:46 <mvollmer> #startmeeting weekly meeting
14:01:46 <zodbot> Meeting started Mon Mar 14 14:01:46 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:46 <zodbot> The meeting name has been set to 'weekly_meeting'
14:01:58 <dperpeet> .hello dperpeet
14:01:59 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:02:03 <mvollmer> .hello mvo
14:02:04 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:02:24 <mvollmer> dperpeet, "None", as in "Numer one"? :)
14:02:31 <stefw> .hello stefw
14:02:32 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:04:20 <mvollmer> #topic agenda
14:04:35 <stefw> * Cleanup of test directory
14:04:41 <mvollmer> * storage polish
14:04:49 <stefw> * Debian repository
14:04:58 <stefw> * Kubernetes container
14:05:36 <mvollmer> anything else?
14:05:53 <mvollmer> #topic Cleanup of test directory
14:06:57 <stefw> I did a pull request which changes the layout of the test directory
14:07:05 <stefw> seems to run now https://github.com/cockpit-project/cockpit/pull/3846
14:07:13 <stefw> there's a silly race with github.com and retrieving of log.html
14:07:29 <stefw> but not a problem in practice
14:07:37 <stefw> and not a new issue introduced by this change
14:07:47 <stefw> I would recommend that anyone that cares take a look at that pull request
14:07:56 <stefw> also make follow up changes to things that would annoy you
14:08:10 <dperpeet> stefw, I think the changes look good
14:08:12 <stefw> it's an insane amount of work to try to get the tests all green, sane, clean and working again
14:08:39 <mvollmer> yeah
14:08:41 <stefw> so if you would like it different or the new change doesn't fit your workflow ... then additional commits are super welcome
14:09:44 <stefw> i think that's it on that topic
14:10:08 <dperpeet> if the log.html works I think it's ready for merging
14:10:10 <mvollmer> okay
14:10:54 <mvollmer> #topic storage polish
14:11:24 <mvollmer> i am trying to fix some smallish things about storage, like using a slider when inputting sizes
14:11:43 <mvollmer> i should make a trello card out of this, but haven't yet
14:12:00 <mvollmer> i am afraid this will result in a number of small patches to storaged
14:12:11 <mvollmer> so this might block on storaged releases
14:12:19 <mvollmer> like the slider stuff does already
14:13:11 <mvollmer> should I quickly share what's on my list?
14:13:17 <mvollmer> it changes quite a bit
14:13:34 <stefw> i think a card would be worth it
14:13:40 <mvollmer> yeah
14:13:44 <stefw> just as easy as typing it here no?
14:13:50 <stefw> or we could just copy paste it in a card?
14:13:51 <mvollmer> so the biggest item might be using lvm to to do raid
14:14:15 <mvollmer> it becomes more official in a card... :-)
14:14:19 <mvollmer> but yeah
14:15:57 <mvollmer> https://trello.com/c/hqj8oZdu/273-storage-polish
14:16:08 <mvollmer> plus all the issues
14:16:58 <stefw> makes sense
14:16:59 <mvollmer> there is really good interest/feedback/help from a couple of people
14:17:24 <mvollmer> so I feel confident that this will turn out satisfactorily
14:17:26 <stefw> yeah that makes it really good timing
14:17:57 <mvollmer> i guess network will need some love as well after this
14:18:14 <mvollmer> but I'll be busy with storage polish for quite some time probably
14:18:18 <mvollmer> month or so?
14:18:40 <mvollmer> but I'll preempt that for more urgent things of course
14:19:37 <mvollmer> that's it from my side
14:20:32 <mvollmer> #topic  Debian repository
14:21:14 <larsu> not many news there - was out thu and fri and looked at the docker stuff otherwise
14:21:36 <stefw> It's probably worth summarizing the current plan
14:21:41 <stefw> and maybe posting it to cockpit-devel
14:22:04 <larsu> ya, I can do that
14:22:07 <stefw> Since I think a custom debian repository is an interim measure, and still needs other folks to help.
14:23:23 <larsu> the long term plan being to push always the latest release into experimental?
14:23:54 <mvollmer> i'd say into unstable
14:24:02 <mvollmer> with all our ci etc
14:24:43 * larsu feels like debian has policy against that
14:24:53 <larsu> but I'm not sure
14:25:10 <stefw> if thehre's a policy against that then this custom repository will contain the latest packaged version
14:25:17 <larsu> right
14:25:18 <mvollmer> we might need to hold off during freezes maybe
14:25:21 <stefw> and a packager can bonk the button to take it and upload it
14:25:23 <dperpeet> well, short term should be experimental
14:25:34 <sgallagh> larsu: Debian and Ubuntu have a special categorization for packages that rebase often.
14:25:47 <larsu> ah, interesting
14:25:50 <sgallagh> It can be requested and hopefully approved (SSSD has that designation, for example)
14:26:17 <larsu> sgallagh: is automatic updating allowed for those?
14:26:43 <sgallagh> Unclear, but I know they don't need to go through as many hoops
14:27:00 <sgallagh> (I'm not a Debian maintainer, I just know that tjaalton did this for SSSD back in the day)
14:27:14 <mvollmer> hmm, maybe uploading weekly to unstable will interfere with the transition to testing
14:27:23 <larsu> ah ok, thanks a lot. I'll look into it
14:27:26 <mvollmer> the package will never be old enough to be considered
14:29:06 <dperpeet> how often we push seems like a detail we don't need to discuss now
14:29:28 <dperpeet> and once we have a maintainer, they'll probably have an opinion on that
14:29:34 <larsu> right
14:29:34 <mvollmer> yep
14:29:53 <dperpeet> they'll be more aware of other effects I hope
14:30:58 <mvollmer> so, anyway, first destination our own repo
14:31:08 <mvollmer> second destination experimental
14:31:11 <mvollmer> and then we see
14:31:13 <mvollmer> right?
14:31:36 <stefw> yup
14:31:40 <larsu> yep, that's what I thought as well
14:31:55 <mvollmer> we should probably get more features working in debian 'asap'
14:32:03 <mvollmer> like storage and networking...
14:32:44 <mvollmer> i mean, working on those doesn't need to wait for any repo work
14:33:20 <larsu> yeah, first thing is getting it into debian user's hands
14:33:28 <larsu> and then let's look at it
14:33:38 <larsu> (or hopefully let more debian people look at it)
14:34:06 <stefw> mvollmer, is the storage stuff working on debian? what about the networking stuff?
14:34:12 <stefw> is that part of your work in those areas?
14:34:33 <mvollmer> storage depends on storaged, which depends on libblockdev
14:34:54 <mvollmer> also storaged needs to decide which API names to use before going into Debian, I feel
14:34:57 <stefw> but there's the udisks work you're doing right?
14:35:16 <larsu> mvollmer: you mean if it goes back to using udisk's?
14:35:25 <larsu> (API names)
14:35:33 <mvollmer> maybe
14:36:37 <mvollmer> i have not worked on cockpit+udisks2
14:36:50 <mvollmer> but I have worked on cockput+storaged-with-udisks2-api-names
14:37:09 <mvollmer> but cockpit+udisks2 should be quite feasible
14:37:28 <mvollmer> although we might lose features, like lvm
14:37:37 <stefw> right for sure
14:37:37 <mvollmer> and also lose silent features like fstab cleanup
14:37:38 <stefw> but i imagine if we're going to spend a lot of time honing the storage stuff ... it would probably be worth it to get it working for debian guys
14:38:20 <mvollmer> yes, cockpit needs to do storage in Debian, I'd say.
14:38:46 <mvollmer> would be quite a failure to not get that sorted ot
14:38:48 <mvollmer> *out
14:39:30 <mvollmer> so, hmm, should I put that higher on the list?
14:39:47 <stefw> in the context of getting storage working better i would say it's quite important
14:39:52 <mvollmer> right
14:40:03 <stefw> but obviously if blocking on storaged choices, then obviously that's a consideration
14:40:03 <larsu> it's working (ish) with storaged that andreas (the other one) packaged...
14:41:32 <mvollmer> yeah, that should be good enough for now
14:41:57 <mvollmer> how storaged goes forward in Debian is another topic
14:42:18 <larsu> and probably not ours to decide on
14:42:42 <mvollmer> yep
14:42:45 <mvollmer> alright
14:43:04 <mvollmer> I'll enable the storage tests on debian somehow
14:43:35 <mvollmer> let's move on
14:43:41 <larsu> let's use the storaged package we have for that, no?
14:43:47 <larsu> oh yeah, let's talk about this separately
14:43:50 <mvollmer> yes, from experimental right?
14:43:53 <mvollmer> okay
14:44:01 <mvollmer> #topic Kubernetes repository
14:44:11 <github> [cockpit] dperpeet pushed 1 new commit to master: https://git.io/valMA
14:44:11 <github> cockpit/master 7ed71bc Stef Walter: test: Increase timeout for troubleshoot machine curtains...
14:44:37 <stefw> Er, that should have been 'Kubernetes container'
14:44:48 <stefw> petervo did a bunch of work to get a kubernetes container ready
14:45:05 <stefw> that's the cockpit kubernetes interface containerized up and deployable on kubernetes itself
14:45:25 <stefw> there's just a couple more pull requests to finish up on documentation
14:45:31 <stefw> and ease of deployment
14:45:44 <mvollmer> (right, sorry)
14:45:54 <stefw> but the basic idea is that on Fedora Atomic, or other places like that, a good way to deploy the kubernetes UI is as a container deployed on kubernetes itself
14:46:23 <stefw> i'm hoping (fingers crossed) that we can get to the point where clicking on a node insude the kubernetes UI will connect to that node in Cockpit
14:46:24 <github> [cockpit] dperpeet pushed 1 new commit to master: https://git.io/valD4
14:46:24 <github> cockpit/master 56d9d0f Stef Walter: networkmanager: Handle race when looking at connection.Masters...
14:46:43 <stefw> so basically this is the base for the "use cockpit against your cluster" use case
14:47:15 <stefw> and petervo is cleaning up lots of my bad code in this container as well, and then the plan is to add kubernetes cluster storage ui in the same place
14:48:31 <stefw> anyway, that's it ... the container is called "cockpit/kubernetes"
14:48:47 <stefw> i think that's it for that topic
14:48:54 <mvollmer> interesting
14:49:14 <mvollmer> i have to admit I find this difficult to follow sometimes... :-)
14:49:24 <stefw> i'll announce more on cockpit-devel once all the ease of use/deployment stuff is sorted
14:50:37 <mvollmer> so Fedora 25 Server, say, would run Cockpit by default and if you want to also have the kube UI, this would happen via the container?
14:51:00 <mvollmer> instead of via installing the cockpit-kubernetes rpm?
14:51:00 <stefw> you can continue to add it as a dashboard if you want
14:51:20 <stefw> But likely if you're running kubernetes, you're not "running a server"
14:51:23 <stefw> at least that's not your focus
14:51:25 <stefw> the focus is on the cluster
14:51:42 <petervo> also atomic doesn't let you install packages
14:51:58 <stefw> and so you would have cockpit essentially running in the cluster, showing you the cluster ... and hopefully letting you access the various cluster machines as servers if you desire.
14:52:36 <mvollmer> so cockpit/kubernetes has cockpit-ws and serves port 9090, and kubernetes routes that somehow to the outside?
14:53:00 <stefw> yup
14:53:12 <mvollmer> right, elegant
14:53:15 <stefw> i think by default it should be the "nodePort" setting and also be accessible on 9090
14:53:36 <stefw> but obviously with more complex kubernetes networking, you get to assign a hostname/url to cockpit and everyone can use it that way
14:54:13 <mvollmer> so "Fedora Atomic 25 Server" would run kube by default and no cockpit, but you can get cockpit as a kube service.
14:54:21 <stefw> yup
14:54:27 <mvollmer> right
14:54:28 <petervo> it's not full cockpit
14:54:37 <petervo> just the kubernetes cluster ui
14:54:44 <mvollmer> yeah, the parts that make sense
14:54:52 <stefw> Also, there's not really Fedora Atomic 25 *Server*
14:55:01 <stefw> it's an OS that's part of the cluster, running random scheduled things
14:55:02 <mvollmer> maybe atomic ostree updates?
14:55:04 <stefw> it's a node
14:55:45 <mvollmer> who is keeping the cluster up-to-date?
14:56:01 <stefw> there's a project from the atomic platform guys to do that
14:56:06 <mvollmer> right
14:56:08 <stefw> build an API and commands to do cluster wide updates
14:56:20 <stefw> and then we'd add some UI that drives that inside of the Cockpit cluster UI
14:56:37 <mvollmer> yes
14:56:45 <mvollmer> thanks
14:57:04 <github> [cockpit] dperpeet closed pull request #3989: docker: Adjust panel height (master...panel-height) https://git.io/valuU
14:58:23 <mvollmer> done?
14:58:31 <stefw> i think so
14:59:12 <mvollmer> okay
14:59:18 <mvollmer> thanks everyone!
14:59:21 <mvollmer> #endmeeting