13:04:02 <andreasn> #startmeeting
13:04:02 <zodbot> Meeting started Mon Aug 31 13:04:02 2015 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:04:11 <andreasn> #topic agenda
13:04:41 <mvollmer> * multipath design
13:04:43 <mvollmer> :)
13:04:44 <stefw> .hello stefw
13:04:46 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
13:04:51 <mvollmer> .hello mvo
13:04:52 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:05:02 <andreasn> .hello andreasn
13:05:03 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:05:06 <stefw> * Listing and filtering pattern
13:06:07 <stefw> * Static linking of cockpit-ws resources
13:06:45 <andreasn> anything else?
13:06:48 <andreasn> ok, lets start
13:06:54 <andreasn> #topic Multipath design
13:08:05 <andreasn> for remote storage?
13:10:03 <mvollmer> ok
13:10:07 <mvollmer> so
13:10:21 <mvollmer> people found out that cockpit does not work with multipath
13:10:34 <subin> stefw: is there way to take snapshot of the screen via the test case
13:10:37 <mvollmer> so i tried to fix the worst things
13:10:47 <stefw> subin, meeting time ^^
13:10:55 <mvollmer> but one thing needs some UI: activating multipath support in the first place
13:11:15 <mvollmer> i still hope this can be avoided by enabling it by default in Fedora Server
13:11:30 <mvollmer> (but haven't pushed yet hard)
13:11:44 <mvollmer> in the mean time, we probably need a button and some explanation
13:11:56 <mvollmer> "your system is broken, press this button to fix it"
13:12:02 <mvollmer> sucks, non?
13:12:07 <stefw> mvollmer, so why would a system have multipath without multipath activated?
13:12:20 <andreasn> what is it that it's activating?
13:12:20 <mvollmer> because it does run out of the box
13:12:28 <mvollmer> it starts multipathd
13:12:43 <stefw> on the other hand having a big standard ui pattern for "unbreak your system" isn't a bad idea in itself
13:13:03 <mvollmer> yeah
13:13:26 <mvollmer> "docker isn't running, press this button to star it"
13:13:52 <stefw> true, but perhaps this is different?
13:13:57 <stefw> at the top like a dismissable alert
13:13:59 <andreasn> are there any downsides of enabling multipathd by default?
13:14:14 <mvollmer> they say it might need configuration
13:14:17 <mvollmer> before starting
13:14:28 <mvollmer> but I hopw we can do config after starting as well
13:14:37 <mvollmer> so it's a bit muddy
13:14:59 <mvollmer> of course, it takes resources, etc
13:15:10 <mvollmer> and if you don't have multipath devices, ...
13:15:18 <mvollmer> but that's not really our part to solve
13:15:30 <mvollmer> udev can start it on demand, maybe
13:15:48 <mvollmer> also, the daemon might not be necessary at all
13:16:09 <stefw> hmmm, seems like we need to figure this out better before designing it, no?
13:16:13 <mvollmer> i don't understand this very well, it seems to be one of the traditional "all options exposed, make your intelligent choice" things
13:16:27 <stefw> well, i think the storaged guys should figure this one out
13:16:37 <stefw> what does multipathd do anyway?
13:16:41 <mvollmer> yes, they are making some apis for storaged
13:16:49 <andreasn> I'm ok with having a "unbreak me" button if something did break, but it's unfortunate if it's in by default
13:16:49 <mvollmer> it monitors the pathes for failures
13:17:07 <stefw> does cockpit setup multipath yet?
13:17:14 <mvollmer> it's in a PR
13:17:16 <stefw> if not, shouldn't we expect a coherent system?
13:17:29 <mvollmer> i would say so
13:17:30 <stefw> that is, if someone else has configured multipath
13:17:42 <mvollmer> anaconda does it, I think
13:17:53 <andreasn> is there a issue in the tracker for it?
13:18:02 <andreasn> for the error happening in the first place that is
13:18:05 <mvollmer> so we can have the button and hope that it never appears
13:19:08 <mvollmer> i think it would be nice to help people out
13:19:12 <andreasn> where does it need to appear? Under the Storage section?
13:19:23 <mvollmer> yes
13:21:27 <mvollmer> i think we can discuss this further outside of the meeting, no?
13:21:30 <andreasn> yep
13:21:48 <andreasn> I must admit I'm not 100% sure what multipath is in detail
13:21:52 <andreasn> how it works
13:22:23 <mvollmer> i can explain that also
13:22:29 <andreasn> sounds great
13:22:30 <mvollmer> let's move on?
13:22:34 <andreasn> yup
13:22:46 <andreasn> #topic Listing and filtering pattern
13:22:58 <stefw> so while andreasn was away ...
13:23:08 <stefw> i worked on a bit of a pattern for use throughout cockpit
13:23:13 <stefw> and it can use some more design help and review
13:23:17 <stefw> we talked about it here and therte
13:23:26 <stefw> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/patterns/listing.png
13:23:34 <stefw> it ties in well with filtering and search/filter bars
13:23:41 <stefw> it aims to:
13:23:46 <stefw> 1. Be discoverable
13:23:55 <stefw> 2. Prevent needless navigation, and so many tiers of navigation
13:24:08 <stefw> 3. Show multiple things on the same page, so you can compare, interact with them together
13:24:16 <stefw> 4. Work well with filtering
13:24:21 <stefw> ... so just a heads up
13:24:32 <andreasn> looks interesting
13:24:33 <stefw> we are using the rather simple Kubernetes Images feature
13:24:40 <stefw> as a way to do a proof of concept
13:24:41 <stefw> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/kubernetes/images.png
13:25:48 <andreasn> does other objects collapse when you expand one or not?
13:26:25 <stefw> yes
13:26:29 <stefw> unless you star an object
13:26:33 <andreasn> ah, ok
13:26:42 <stefw> by default yes, that's the first simple use case that the user discovers
13:26:47 <stefw> "just view one thing at a time"
13:28:55 <andreasn> and this is for both the Container page and the Kubernetes page, right?
13:29:04 <stefw> and others
13:29:08 <stefw> like network interfaces
13:29:16 <stefw> if we can get this right
13:29:23 <stefw> we can use this instead of the panel listings we have now
13:29:36 <stefw> something like this would be perfect on the 'Services' section
13:29:42 <stefw> it would really bring it togethr
13:29:43 <andreasn> yeah
13:29:45 <stefw> when combined with filtering
13:30:08 <andreasn> services really needs some kind of filtering
13:30:41 <andreasn> networking, maybe
13:31:01 <stefw> yeah, networking doesn't need filtering so much
13:31:11 <stefw> but you really do want to not have to navigate so much
13:31:16 <stefw> in addition, if only one item is in the listing
13:31:20 <stefw> you could expand it into a panel by default
13:31:31 <andreasn> but we can start with containers and then services
13:31:32 <stefw> and thus make it realy easy to go
13:31:34 <stefw> right
13:31:36 <stefw> networking is harder
13:31:45 <stefw> if we can get to storage one day, by using some elements of this
13:31:47 <stefw> it would really be cool
13:31:50 <stefw> but that's the hardest
13:31:53 <andreasn> yes
13:32:03 <stefw> anyway, we'll try this out in the kubernetes section
13:32:07 <andreasn> sounds good
13:32:15 <stefw> and obviously it probaly needs tweaking and testing
13:33:37 <stefw> that's it for that topic
13:33:43 <andreasn> all right, next up
13:33:49 <andreasn> #topic Static linking of cockpit-ws resources
13:35:18 <stefw> i'm working on the pretty HTTP failure messages using patternfly black slate design
13:35:23 <stefw> and have most of it doen
13:35:34 <stefw> https://github.com/cockpit-project/cockpit/pull/2656
13:35:52 <stefw> as part of that, we link in the fail.html error page into the cockpit common code
13:35:58 <stefw> so that cockpit-bridge and cockpit-ws can use it
13:36:01 <stefw> as part of the executable
13:36:08 <stefw> i was wondering if we wanted to do that with the other static resources?
13:36:15 <stefw> i have a branch that does it, but i'm not sure it's a good idea
13:36:19 <stefw> so that would be login.html
13:36:21 <stefw> and the fonts
13:37:28 <stefw> mvollmer, petervo, what do you think?
13:37:57 <mvollmer> hmm
13:38:08 <mvollmer> they would go into the executable?
13:38:15 <stefw> yes
13:38:22 <stefw> the fail.html one pretty much has to go into the executable
13:38:27 <stefw> but this question is about the others
13:38:28 <petervo> does cockpit-bridge ever need login.html?
13:38:32 <stefw> using the standard GResource framework
13:38:38 <stefw> no cockpit-bridge doesn't need login.html
13:38:41 <mvollmer> right
13:38:41 <stefw> these additional static resources
13:38:43 <stefw> would go into cockpit-ws
13:38:48 <stefw> and not into libcockpit-common.a
13:38:55 <stefw> in other words they wouldn't be present in all the executables
13:39:20 <mvollmer> i think it makes sense for the failure page, but not so much for the rest
13:40:00 <stefw> ok
13:40:11 <mvollmer> it is unexpected, no?
13:40:19 <stefw> not sure
13:40:21 <mvollmer> what would be the reason?  performance?
13:40:28 <stefw> yeah, performance, simplicity
13:40:36 <stefw> but since the branding won't be merged
13:40:44 <stefw> i think perhaps this won't have the benefit expected
13:40:50 <stefw> the branding wouldn't be linked in anyway
13:41:02 <stefw> so yeah, i agree, maybe not that great
13:44:11 <andreasn> anything more on that topic?
13:44:18 <stefw> nope
13:44:25 <andreasn> all right
13:44:31 <stefw> I have one more agenda item though
13:44:32 <andreasn> #topic Open floo
13:44:36 <andreasn> shoot
13:44:43 <stefw> https://github.com/cockpit-project/cockpit/pull/2654
13:45:05 <stefw> the pull request links from a failure on the login screen to files.cockpit-project.org
13:45:08 <stefw> is that something we want to do?
13:45:28 <stefw> i've seen so many cases where websites have gone down, and links are broken in released software
13:45:43 <stefw> but maybe i'm thinking too old skool
13:46:04 <andreasn> what does it link to on files.cockpit ?
13:46:14 <petervo> the authentication guide
13:46:16 <mvollmer> the docs are for the person setting up cockpit, which might not be the guy using it
13:46:26 <mvollmer> so the link might not be very helpful
13:46:29 <andreasn> ah, documentation
13:46:40 <stefw> mvollmer, i agree
13:47:21 <mvollmer> we could put a button there "enable password login"
13:47:24 <mvollmer> :-)
13:47:33 <andreasn> http://files.cockpit-project.org/guide/authentication.html <- gives a 404
13:47:46 <mvollmer> it'll be there after pr is merged
13:47:49 <mvollmer> i think
13:47:59 <andreasn> ah
13:48:00 <stefw> it'll be at guide/latest/
13:48:04 <stefw> which just goes to show
13:48:08 <stefw> either we need a solid infrastructure for this
13:48:12 <stefw> or we don't do it
13:48:16 <stefw> like if we want to do it
13:48:18 <stefw> we need a redirector
13:48:32 <andreasn> I guess the distributor might replace that url with some URL to their documentation possibly
13:48:41 <andreasn> but that's a distributor patch in that case
13:49:40 <mvollmer> could be part of branding
13:49:50 <petervo> well we can put in a generic "see the docs" text
13:50:08 <petervo> which is pretty unhelpful for something already in the browser
13:50:08 <stefw> we should probably make the error messages the best we can
13:50:13 <stefw> and have see the docs be implied
13:50:30 <petervo> or we can provide a way to load the docs unauthenticated in cockpit
13:50:31 <stefw> there could be a hundred reasons why a login fails right?
13:50:41 <mvollmer> I was proposing that we don't show the user/password fields at all when we know that password login wont work
13:50:49 <petervo> we don't know till we try
13:50:51 <stefw> but we only know that after we connect to the server
13:50:58 <stefw> like after we do an ssh handshake and all
13:51:09 <andreasn> so this shows up for all login failures? Like also wrong username or password?
13:51:14 <stefw> it's easy for a machine to be configured to only allow password auth for non-root
13:51:16 <petervo> no
13:51:48 <petervo> only when ssh couldn't agree on a auth method to use
13:52:11 <stefw> pretty much the server won't allow cockpit to authenticate
13:52:13 <andreasn> ah, I see
13:52:21 <stefw> there's nothing the user can do through cockpit at that point
13:53:35 <petervo> anyone have an opinion on having cockpit serve it's own docs
13:53:47 <petervo> cockpit-ws
13:54:04 <stefw> hmmm, worth thinking about
13:54:14 <stefw> especially if installing them is optional
13:54:31 <stefw> although again, the docs aren't really supposed to be end user docs
13:54:32 <andreasn> would fix the website with the docs are down, or firewalls
13:54:42 <stefw> they're supposed to be for deployers and developers
13:55:44 <petervo> well there really isn't a end a unprivileged user can do at this point
13:55:44 <andreasn> if I saw "Cockpit was unable to attempt to authenticate you using any supported authentication methods." I would copy that and just paste it into google
13:55:59 <stefw> If we know we tried password auth
13:56:04 <stefw> we can print a better message
13:56:05 <andreasn> then find some old ubuntu forum that said "just paste this into a terminal and it will go away" :)
13:56:34 <stefw> "The server does not support password authentication"
13:56:57 <petervo> but maybe the user should have been using sso
13:56:59 <stefw> "The refused to authenticate 'x' using password authentication, and no other supported authentication method is available."
13:57:08 <stefw> ^^
13:57:23 <stefw> "The refused to authenticate 'root' using password authentication, and no other supported authentication method is available."
13:57:30 <andreasn> The?
13:57:33 <stefw> although we could tweak that to be even better
13:57:38 <stefw> "The server refused to authenticate 'root' using password authentication, and no other supported authentication method is available."
13:58:01 <andreasn> sounds sane
13:58:06 <stefw> and it has a sense of finality
13:58:14 <stefw> like ... listen buddy, this isn't going to work
13:58:18 <andreasn> hehe
13:58:22 <stefw> unless the server is changed somehow
13:58:29 <andreasn> it's good that it doesn't mention "Cockpit"
13:58:36 <stefw> i think this is outside of cockpit
13:58:54 <stefw> and that's implied no?
13:58:59 <stefw> but please do feel free to adjust if not
13:59:24 <andreasn> I think it's good like this
13:59:46 <petervo> should i dump the rest of the doc changes from that PR as well then?
13:59:54 <stefw> no
13:59:59 <stefw> the docs are awesome
14:01:13 <petervo> ok, i'll make the messaging changes
14:03:49 <andreasn> that's all for today?
14:04:12 <stefw> that's it for me
14:04:27 <mvollmer> yep
14:04:48 <andreasn> #endmeeting