cockpit
LOGS
13:01:46 <mvollmer> #startmeeting
13:01:46 <zodbot> Meeting started Mon Sep 21 13:01:46 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:01:51 <mvollmer> .hello mvo
13:01:52 <dperpeet> .hello dperpeet
13:01:52 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:01:58 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:03:50 <dperpeet> * migration from old shell pages to packages
13:04:03 <andreasn> * multipath errors
13:04:19 <dperpeet> .hello andreasn
13:04:20 <zodbot> dperpeet: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:04:22 <andreasn> hups
13:04:25 <andreasn> yes
13:04:30 <andreasn> * ostree updates
13:05:03 <mvollmer> * iscsi
13:05:10 <dperpeet> * libvirt for testing
13:08:36 <mvollmer> okay!
13:08:41 <petervo> should we start?
13:08:47 <dperpeet> yes please
13:08:57 <mvollmer> #topic migration from old shell pages to packages
13:09:18 <dperpeet> I started out investigating a regression in the datetime dialog #2777
13:09:27 <dperpeet> I opened a pull request here https://github.com/cockpit-project/cockpit/pull/2787
13:09:46 <dperpeet> I believe the error to stem from a jquery selector https://github.com/cockpit-project/cockpit/pull/2787/files#diff-06cf3683b896cf3916c0439d444a5b27R1163
13:10:00 <dperpeet> in a "hack" piece of the code to support the legacy pages
13:10:30 <dperpeet> be aware that there might be other issues that stem from these selectors, since we have used this piece in a few places I believe
13:10:50 <dperpeet> I noticed that the "enter" event was being called every time the datepicker control opened
13:11:31 <dperpeet> I don't think it's worth putting too much time into fixing this, since the code is temporary anyway
13:11:42 <dperpeet> unless there are actual issues
13:11:55 <dperpeet> end of topic
13:11:57 <mvollmer> enter is supposed to be called every time, no?
13:12:04 <dperpeet> when you open the page
13:12:11 <dperpeet> not when you click inside a field in the page
13:12:27 <mvollmer> correct
13:12:39 <mvollmer> but it should be called every time a dialog opens, on that dialog.
13:12:46 <dperpeet> yes
13:12:56 <mvollmer> ohh, I get it!
13:12:58 <mvollmer> sorry
13:13:07 <mvollmer> the datepicker control is not the dialog
13:13:13 <mvollmer> carry on, carry on
13:13:19 <dperpeet> yeah, the selector caught sub-controls
13:13:25 <mvollmer> right
13:13:31 <dperpeet> it's a hack on top of a fix
13:13:32 * stefw was spacing out
13:13:36 <dperpeet> but good enough I believe
13:14:03 <mvollmer> we could check this in the event handler
13:14:15 <dperpeet> too see how many elements are caught?
13:14:16 <dperpeet> we could
13:14:24 <dperpeet> but like I said... I wouldn't, unless there are actual errors
13:14:35 <dperpeet> just be aware if we add controls et cetera
13:14:37 <mvollmer> i meant, we could check the "this" variable
13:14:42 <dperpeet> hm
13:14:52 <mvollmer> anyway, let's do that in the PR, no?
13:15:01 <dperpeet> yes
13:15:06 <mvollmer> ok
13:15:07 <dperpeet> it needs to work today
13:16:42 <mvollmer> okay
13:16:47 <mvollmer> do you need help with it?
13:17:13 <dperpeet> we can discuss it in the pull request I believe
13:17:41 <mvollmer> okay
13:18:11 <mvollmer> #topic multipath errors
13:18:15 <mvollmer> andreasn?
13:18:25 <andreasn> yup
13:18:41 <andreasn> so me and mvollmer discussed https://github.com/cockpit-project/cockpit/pull/2601 a bit
13:19:05 <andreasn> it needs some fixing to the css and some fixes to the wording
13:19:24 <andreasn> and I hope to get around to doing that today
13:19:33 <mvollmer> and a fix to the behavior
13:19:42 <mvollmer> so that we don't show both errors at the same time
13:19:47 <andreasn> yes
13:20:49 <mvollmer> i'd say that after that, Cockpit is ready for multipath
13:21:02 <stefw> we've listed multpath on our F23 improvements
13:21:05 <mvollmer> but of course we don't know what people want to do
13:21:26 <mvollmer> so let's reach out to the expoerts
13:21:30 <andreasn> we'll need to figure out how multipath over iscsi will work at some point
13:21:35 <mvollmer> *ex-poets
13:22:04 <mvollmer> i think it is orthogonal
13:23:01 <mvollmer> next?
13:23:03 <andreasn> yes
13:23:18 <mvollmer> #topic ostree updates
13:23:54 <andreasn> this is the latest version of the mockup https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/software-updates/software-updates-ostree-alt.png
13:24:54 <andreasn> petervo, stefw: does these look ok?
13:25:14 <stefw> i think it's good to go. I'd like to do a bit of sprucing up of the css
13:25:21 <stefw> but that doesn't need to block anything
13:25:33 <andreasn> sounds good
13:26:08 <andreasn> all right, next?
13:27:03 <mvollmer> #topic iscsi
13:27:10 <mvollmer> good progress
13:27:23 <mvollmer> starting to understand the concepts
13:27:42 <mvollmer> i am implementing the mockup straight through, pretty much
13:27:55 <mvollmer> discovery works, login is next
13:28:21 <mvollmer> andreasn and I had some discussion about some details already
13:28:42 <andreasn> like if we can change the IQN for example
13:28:45 <andreasn> or not
13:28:53 <mvollmer> maybe the storaged API is too limited, maybe the mockup has too much stuff
13:29:02 <mvollmer> yes, like the IQN
13:29:11 <mvollmer> and whether we can decide which LUNs to add.
13:29:18 <mvollmer> or whether we always get all
13:29:45 <andreasn> I haven't looked into iscsi since the spring, so I'll need to research it a bit
13:29:57 <mvollmer> so my idea is now that I take the storaged API as gospel, and then we show the thing to the 'customer'.
13:30:06 <andreasn> sure
13:30:35 <mvollmer> and if/when there is feedback, we act on it
13:31:16 <mvollmer> so estimate, initial PR before the end of this week.
13:31:25 <andreasn> cool
13:31:38 <mvollmer> after that, I am thinking to work a bit on scalability
13:31:52 <mvollmer> mostly to see how bad it actually is
13:32:05 <andreasn> X number of LUNs?
13:32:18 <mvollmer> but I can pick a cart on trello as well
13:32:26 <andreasn> yeah
13:32:50 <mvollmer> *card
13:33:08 <mvollmer> next?
13:34:09 <andreasn> yeah
13:34:14 <mvollmer> #topic libvirt for testing
13:34:33 <dperpeet> well, today I ran into some python crashes (double linked lists apparently)
13:34:48 <dperpeet> which might be happening in the libvirt api
13:35:10 <github> [cockpit] stefwalter opened pull request #2790: systemd: Render unit when it goes from invalid to valid (master...render-unit-fix) http://git.io/vn4Ja
13:35:19 <dperpeet> so I added a bit of stability code and more verbose handling of resources (libvirt connections et cetera)
13:35:50 <dperpeet> other than that virt-builder is currently aborting, so I have to see if that is my fault :)
13:35:55 <mvollmer> the crash looked like it was inside malloc, actually.
13:36:20 <stefw> memory corruption?
13:36:26 <dperpeet> I hope not :o
13:36:47 <dperpeet> python bindings for libvirt are compiled from c code
13:36:52 <mvollmer> libvirt is C? and is linked into the Python interp?
13:36:54 <dperpeet> so there might be an error lurking somewhere
13:37:05 <mvollmer> right
13:37:26 <stefw> valgrind?
13:37:31 <dperpeet> I'm hopeful to reproduce this more cleanly tonight (or have it working?)
13:37:40 <dperpeet> right now I need to get the builder working again
13:37:55 <mvollmer> hmm
13:38:11 <mvollmer> virt-build should be totally independent from our testvm.py crazyness
13:38:16 <dperpeet> yes
13:38:37 <dperpeet> /home/dev/.cache/virt-builder/fedora-22.x86_64.1: No space left on device
13:38:41 <stefw> i'm not so sure about totally independent
13:39:06 <stefw> mvollmer, we need the right ip addresses, and hostnames in order to do a successful install of ipa and/or openshift (at least)
13:39:06 <dperpeet> I will test on master later today
13:39:20 <dperpeet> that's afterwards though
13:39:21 <dperpeet> I think
13:39:29 <dperpeet> when we run our script
13:39:33 <mvollmer> stefw, true
13:39:34 <stefw> right
13:39:52 <dperpeet> builder should deliver what we consider to be an out-of-the-box system
13:40:07 <dperpeet> we could move a lot of what we do into the builder (ssh keys, passwords, users...)
13:40:23 <dperpeet> but right now we have the "clean" divide between upstream and our mess
13:40:50 <dperpeet> anyway, if I need help I'll shout out
13:40:55 <dperpeet> otherwise this was just a status update
13:41:06 <dperpeet> I had hoped for this to be finished by now :)
13:43:21 <mvollmer> yep... :-)
13:43:30 <mvollmer> #topic Any other business
13:43:36 <stefw> yup, i have another agenda item
13:43:46 <stefw> * URL compatibility issues
13:43:57 <stefw> Mind if I go ahead?
13:44:22 * stefw guesses so
13:44:34 <mvollmer> yes, please
13:44:35 <stefw> So basically as we migrated things to components, we broke multi-machine for those menu items
13:45:06 <stefw> as things moved out of shell/shell.html older cockpit's no longer knew where to find those things ... and newer cockpits no longer looked at shell/shell.html when accessing certain menu items on old cockpit machines
13:45:11 <stefw> Leading to lots of "Not Found"
13:45:28 <stefw> the root cause of this was obviously (my) shortsightedness
13:45:58 <stefw> So ... we've tried to fix this somewhat by having newer cockpits detect when an older cockpit is in use and try shell/shell.html for certain menu items
13:46:31 <stefw> however the problem remains: if an old cockpit instance adds a new one to the dashboard, most of the server menu items will just fail
13:46:45 <stefw> there is one way to fix this: rename the component paths
13:47:10 <mvollmer> in the newer versions?
13:47:13 <stefw> yup
13:47:18 <stefw> obviously that would break bookmarks and such
13:47:41 <stefw> but at this point it's choosing between various problems ... and figuring out which one is worse
13:47:58 <mvollmer> would we also need to provide a full pkg/shell again?
13:48:02 <stefw> nope
13:48:31 <mvollmer> right, because the fallback code doesn't trigger in the old index.js
13:48:36 <stefw> yup
13:48:47 <stefw> one problem that exists: switching between servers while on a section
13:48:59 <stefw> will not jump to the new component
13:49:02 <stefw> because they have different paths
13:49:25 <mvollmer> hmm
13:49:31 <stefw> this issue unfortunately already exists somewhat, if in a certain sub-hash of component
13:49:42 <stefw> anyway ... all of this is rather messy
13:49:46 <stefw> and i'd really like to clean it up
13:49:55 <stefw> i've been working on #1788 and #2789
13:50:05 <stefw> in order to finalize what we have in our component urls
13:50:30 <stefw> and if we have the need/opportunity to change user visible urls then i'd like to clean those up too as well as some of the behavior associated with them.
13:50:49 <mvollmer> yes
13:51:20 <mvollmer> i have the feeling that we don't need to care about old versions too much yet
13:51:31 <mvollmer> or do we?
13:51:37 <stefw> we said we did
13:51:37 <mvollmer> in rhel?
13:51:44 <mvollmer> yeeeees
13:51:48 <stefw> no, RHEL doesn't care so much
13:51:57 <stefw> because in RHEL Extras ... you don't get support unless you're using the latest version
13:52:34 <mvollmer> right
13:52:49 <mvollmer> fedora 21 is abandoned already, right?
13:52:59 <stefw> i think so
13:53:02 <stefw> or very nearly
13:53:11 <mvollmer> i mean, by us.
13:53:38 <stefw> right
13:53:41 <petervo> we don't update it anymore
13:53:57 <mvollmer> and we don't support adding it to a dashboard, right?
13:54:02 <stefw> right
13:54:41 <mvollmer> do we like our current URLs?
13:54:45 <mvollmer> I am not so sure.
13:55:06 <stefw> i have a proposal for what i think is much better:
13:55:33 <mvollmer> Can we have <host>/storage/ instead of <host>/storage/devices, for example?
13:55:39 <stefw> https://raw.githubusercontent.com/stefwalter/cockpit/8b4b80894996047a19587a6b352c75d641170197/doc/guide/urls.xml
13:55:42 <stefw> mvollmer, yes
13:55:49 <stefw> so component urls don't change (much)
13:56:00 <stefw> only the addition of /cockpit+embedder there ... as we discussed before
13:56:06 <stefw> but the user visible urls change
13:56:11 <stefw> so we have:
13:56:24 <stefw> http://10.10.10.10/storage
13:56:33 <stefw> http://10.10.10.10/@other/storage
13:56:42 <stefw> http://10.10.10.10/storage#/my/sub/hash
13:56:56 <stefw> http://10.10.10.10/docker#/mycontainer
13:57:13 <stefw> the entire hash is passed to the components == very predictable understandable
13:57:21 <stefw> @host is only present when accessing a non-local host
13:57:32 <stefw> (having "localhost" in the url was confusing to people trying to understand things)
13:57:40 <stefw> components can have an index.html
13:57:52 <stefw> http://10.10.10.10/system
13:57:56 <stefw> loads system/index.html
13:58:05 <stefw> and http://10.10.10.10/system/services
13:58:05 <dperpeet> I like leaving it up to components what to do with the hash part
13:58:08 <stefw> loads system/services.html
13:58:25 <dperpeet> and not worry about the other stuff
13:58:49 <mvollmer> sounds great
13:58:58 <stefw> this uses pushState and replaceState
13:59:01 <stefw> oh, one last thing
13:59:07 <stefw> always change the url for /
13:59:29 <stefw> so you would never (for better or worse) end up with a url like http://10.10.10.10:9090/
13:59:41 <stefw> but always would display either: http://10.10.10.10:9090/system
13:59:42 <stefw> or
13:59:48 <stefw> http://10.10.10.10:9090/dashboard
13:59:58 <stefw> unfortunately having / display a valid page, ended up with bugs like this:
13:59:59 <petervo> what about hard reloads?
14:00:30 <stefw> in cockpit-ws we answer everything with '@machine' and/or a valid package name as the first path component with index.html
14:00:40 <stefw> everything else is under /cockpit...
14:00:48 <stefw> obviously no package can be called 'cockpit'
14:00:51 <stefw> but we can check for that
14:01:11 <stefw> this is normal when using pushState() or replaceState() ... although people typically do this with mod_rewrite
14:01:17 <stefw> see trello for example
14:01:38 <stefw> anyway, #2789 is what makes this all possible
14:02:09 <stefw> all urls need to be relative anyway to make that work
14:02:10 <mvollmer> okay, then we agree that we fix the comp problem by using different URLs?
14:02:22 <mvollmer> or would the new scheme introduce more comp probs?
14:02:39 <stefw> there would be the case of switching between hosts (mentioned above)
14:02:43 <stefw> but that needs to be f ixed anyway
14:03:07 <stefw> where if you're on a certain component, and the other host doesn't have that component
14:03:10 <stefw> then you get 'Not Found'
14:03:20 <mvollmer> right
14:03:37 <mvollmer> what if a old dashboard has a machine on it with the new URL scheme?
14:03:42 <mvollmer> does it all work?
14:03:55 <stefw> yes, the components themselves don't change url scheme with this at all
14:03:58 <mvollmer> or are there problems because we have changed how chashes work etc?
14:04:03 <stefw> only the user visible URLs
14:04:05 <mvollmer> ahh, I see.
14:04:08 <stefw> no they don't change
14:04:36 <mvollmer> very nice
14:05:56 <stefw> anyway, the first step to this is reviewing #2788 and #2789
14:06:10 <stefw> if we're going to do this, i would like to have it done as soon as possible
14:06:13 <stefw> our next release is coming up shortly.
14:06:42 <stefw> i think i've done about half of it already
14:06:45 <stefw> with the work on #2789
14:07:20 <mvollmer> okay, first thing tomorrow
14:07:35 <stefw> or petervo do you have time to review?
14:07:50 <stefw> because then i can try and have the second half ready by sometime tomorrow morning
14:07:59 <petervo> sure
14:09:28 <stefw> i'll get to work then
14:09:41 <stefw> if that's it for the meeting
14:10:00 <mvollmer> i think it is.
14:10:04 <mvollmer> thanks everyone!
14:10:09 <mvollmer> #endmeeting