14:01:05 <mvo_> #startmeeting
14:01:05 <zodbot> Meeting started Mon Feb 23 14:01:05 2015 UTC.  The chair is mvo_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:16 <mvo_> #meetingname Cockpit Weekly Meeting
14:01:16 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting'
14:01:25 <mvo_> uh, fail already
14:01:26 <andreasn_> mvo_: thanks!
14:01:38 <mvo_> #meetingtopic Cockpit Weekly Meeting
14:02:02 <mvo_> #char andreasn_ stefw dperpeet petervo
14:02:07 <mvo_> #chair andreasn_ stefw dperpeet petervo
14:02:08 <zodbot> Current chairs: andreasn_ dperpeet mvo_ petervo stefw
14:02:19 <mvo_> anyone else wants a chair?
14:02:38 <mvo_> #topic Agenda
14:02:51 <stefw> * Integration tests on Fedora 22
14:02:54 <andreasn_> * PCP
14:03:11 <stefw> * Simplifying the package loading
14:03:31 <andreasn_> * Software updates OSTree/RPM
14:03:56 <andreasn_> * Patternfly update
14:04:01 <stefw> * Storage refresh and storaged
14:04:42 <mvo_> looks like enough
14:04:45 <stefw> :)
14:04:48 <mvo_> * Open floor
14:04:57 <andreasn_> there is also Open Floor at the end if we forgot anything
14:05:02 <mvo_> #topic  Integration tests on Fedora 22
14:05:25 <mvo_> yep, as soon as possible
14:05:47 <mvo_> I guess we have to do those without Jan's work, right?
14:06:14 <mvo_> we could just switch from F21 to F22, or we could add F22.
14:06:18 <mvo_> opinions?
14:06:37 <mvo_> (or we could first switch to F22 and then add F21 back with lower prio.)
14:06:59 <dperpeet> I think switch to F22 and add F21 with lower priority for now
14:07:15 <dperpeet> we don't want to start a habit of tracking lots of old versions unless there is actual demand
14:07:15 <mvo_> yeah
14:07:24 <mvo_> we still have the copr for f21
14:08:57 <mvo_> #action mvo_ make/find a magic base tarball for F22 and investigate what else needs to be done
14:09:35 <mvo_> I guess F22 == rawhide right now, correct?
14:10:16 <andreasn_> isn't 23 = rawhide now?
14:10:22 <mvo_> i don't know
14:12:00 <andreasn_> pavlix in #fedora-devel said rawhide = 23
14:12:03 <mvo_> ok, but let's get this rolling this week.
14:12:11 <mvo_> next topic?
14:12:30 <andreasn_> yeah
14:12:38 <mvo_> #topic PCP
14:12:56 <mvo_> Ok, there is a pull request now that adds the last bu
14:13:07 <mvo_> ...last bit: the on/off button.
14:13:11 <andreasn_> bunch of action happening here https://github.com/cockpit-project/cockpit/pull/1816
14:13:25 <andreasn_> so yeah, what was the conclusion with that?
14:13:38 <mvo_> yeah, zooming UX is being polished and I think we are happy with the current plan, right?
14:13:46 <andreasn_> yes
14:14:05 <andreasn_> so with the on/off.. It will be possible to turn off, but it will turn on itself again?
14:14:07 <andreasn_> ?
14:14:10 <mvo_> i am somehow unhappy but can't put it into words yet
14:14:30 <mvo_> andreasn_, no, forget about that.
14:14:41 <andreasn_> unhappy with what? the zooming?
14:14:55 <mvo_> no, unhappy with pmlogger
14:15:02 <andreasn_> ah, right
14:15:23 <andreasn_> lets trick harald into making it a systemd feature :)
14:15:26 <mvo_> it does all work, but we don't show failures, for example.
14:15:48 <stefw> :)
14:16:20 <mvo_> so there are bugs, but are they showstoppers?  I have to reflect about that.
14:16:34 <andreasn_> how reliable does it feel?
14:17:01 <mvo_> or in other words, how much do we make pcp's general systemd integration our problem?
14:17:38 <mvo_> andreasn_, if you stick to the On/Off button it's reliable.
14:17:45 <andreasn_> ok
14:18:42 <mvo_> but if you touch the pcp config directly and start services yourself etc, then things might get unreliable.
14:18:51 <andreasn_> ooh
14:19:15 <mvo_> and we could say "yeah, pcp is like that"
14:19:18 <github> [cockpit] stefwalter closed pull request #1840: shell: Set server time implementation (master...systime) http://git.io/AmAs
14:19:47 <dperpeet> doesn't that contradict our principles?
14:20:07 <andreasn_> it does slightly
14:20:40 <andreasn_> cockpit won't destroy your system, but the system can destroy it for cockpit
14:20:41 <dperpeet> very much so - that means you can't really use the config and cockpit interchangeably
14:20:52 <sgallagh> Hello folks. Sorry I'm late to the meeting. My F22 system was broken by a GDM update this morning :(
14:21:15 <mvo_> dperpeet, no, the pcp breakage would not be cockpit specific.
14:21:20 <mvo_> we just don't help much
14:21:22 <andreasn_> sgallagh: happened to me too in a vm
14:21:42 <andreasn_> sgallagh: but it seems Ray is aware of the issue
14:21:44 <sgallagh> /me tries to run the latest stuff on his laptop all the time, so I catch these things before our users
14:21:46 <mvo_> e.g., if pmcd isn't running when you start pmlogger, then pmlogger will fail, but systemd doesn't know about it.
14:22:02 <sgallagh> Yeah, he pushed a fix for it about 30 minutes ago which I was able to update to
14:22:46 <dperpeet> mvo_, ok, that sounds acceptable in a beta-kind of way
14:23:30 <andreasn_> and it doesn't sound like it's broken for only us
14:23:41 <mvo_> so we have the situation where "switch it off and on again" will actually magically fix your system.
14:23:50 <andreasn_> haha
14:24:07 <mvo_> ok enough about pcp
14:24:28 <andreasn_> yeah
14:24:48 <mvo_> #action mvo_ make sure we know what we really need to have fixed in pcp.
14:25:09 <andreasn_> is the fallback plan to back it out?
14:25:27 <mvo_> andreasn_, no fallback plan yet.
14:25:35 <stefw> andreasn_, no
14:25:43 <andreasn_> ok
14:25:43 <stefw> probably make it optional
14:25:50 <andreasn_> right
14:25:52 <stefw> er, that would probably be the fallback
14:25:58 <andreasn_> ok, next topic?
14:26:04 <mvo_> it's different for F22 and Atomic
14:26:28 <mvo_> #topic Simplifying the package loading
14:27:21 <stefw> that's me
14:27:35 <stefw> so as we approach Fedora 22, where we want our protocol to be stable ...
14:27:55 <stefw> i took a look at how to incorporate the lessons we learned in our package system
14:28:00 <stefw> and basically make it much simpler
14:28:10 <stefw> this doesn't affect the actual package layout that much
14:28:24 <stefw> but changes the expectations about cockpit packages
14:28:26 <stefw> in particular:
14:28:46 <stefw> * machines only share resources in the browser cache if all their packages are identical (one checksum per machine)
14:29:25 <stefw> * we should be able to share ui between packages and components
14:29:28 <stefw> (like dialogs)
14:29:42 <stefw> * we never mix package resources (js, html, css, etc.) from multiple servers in a single document
14:30:08 <stefw> * all urls and src's are relative paths
14:30:20 <stefw> https://github.com/cockpit-project/cockpit/pull/1841
14:30:22 <stefw> implementation is done
14:30:29 <stefw> i need to clean up the commits, and add a few more tests
14:30:36 * stefw is done with the summary
14:30:52 <andreasn_> cool
14:31:30 <mvo_> very good
14:31:37 <mvo_> questions? :-)
14:32:09 <stefw> oh, by the way
14:32:19 <stefw> we use a localhost http serverc in cockpit-bridge
14:32:41 <stefw> and just send the (authenticated, package related) http requests through our http-stream1 channels from cockpit-ws to be answered by the bridge
14:32:49 <stefw> so no more resource2 channel
14:33:22 <mvo_> neat
14:33:25 <dperpeet> sounds good - only explain in the text (Plan) why you install packages in .../cackpit :)
14:33:37 <mvo_> http-stream1 is also used for docker, right?
14:33:39 <dperpeet> ... or change it to cockpit
14:34:15 <stefw> :)
14:36:17 <stefw> mvo_ yes http-stream1 is used for docker and kubernetes
14:36:24 <mvo_> ok
14:36:24 <stefw> next topic?
14:36:39 <mvo_> #topic Software updates OSTree/RPM
14:37:07 <petervo> i don't have much new to show or report
14:37:30 <stefw> petervo, are you interested in changing the scope of the current work?
14:37:40 <stefw> now that you've done the research and have worked with different upstreams?
14:39:23 <petervo> for atomic i don't think there is much room to change the scope, though there is still a lot of work to do
14:39:30 <stefw> right
14:40:22 <petervo> for packagekit, changing it might be an option
14:41:09 <stefw> well, yes up to you. we could do one after the other instead of both at the same time
14:41:13 <stefw> if that's easier for you.
14:41:49 <mvo_> petervo, for Atomic we need a rewrite of ostree with D-Bus, right?
14:42:00 <mvo_> and for F22, some enhancements for PackageKit?
14:42:01 <petervo> rpm-ostree
14:42:27 <stefw> and also dependency work for PackageKit
14:42:41 <mvo_> to make it acceptable for Fedora Server?
14:42:50 <mvo_> (the X11 stuff?)
14:42:58 <stefw> yes. as i understand it.
14:43:01 <petervo> yeah unless we fix that no one will want it on their servers
14:43:03 <mvo_> right
14:43:15 <mvo_> sgallagh, still here?
14:43:16 <petervo> it needs a few changes, there is a PR pending
14:43:24 <sgallagh> mvo_: Somewhat
14:43:30 <sgallagh> What's the question
14:43:37 <petervo> we also need something to trigger the updates
14:43:38 <sgallagh> /me reads back
14:43:42 <petervo> for servers
14:43:56 <mvo_> sgallagh, how much do you want "OS Updates" to be a feature of Cockpit in F22?
14:44:21 <mvo_> (I guess you had that discussion... but let's have it again.)
14:44:22 <petervo> we could do that entirely from cockpit
14:44:38 <sgallagh> mvo_: That would be really nice, certainly.
14:44:45 <stefw> i'm not aware that we had that on the list for F22
14:44:51 <sgallagh> Right now, that's firmly in the "you have to SSH in to do that" category
14:44:57 <stefw> it's not here: https://trello.com/c/duRQw1rU/113-milestone-fedora-22
14:45:03 <mvo_> stefw, ohh, did we not?
14:45:12 <sgallagh> But yeah, this is the first I'm hearing of that being an F22 target
14:45:12 <stefw> nope, it's here: https://trello.com/c/J7dys6gA/114-milestone-rhel
14:45:34 <mvo_> ahh, I see.
14:46:22 <mvo_> does it make sense to have this for RHEL but not Fedora?
14:46:32 <petervo> not really
14:46:40 <petervo> but it just means different deadlines
14:46:59 <stefw> it'll land in Fedora, obviously ... but it's not F22
14:47:07 <stefw> unless magic happens
14:47:13 <dperpeet> the hurdles for rhel are slightly higher
14:47:19 <dperpeet> that's why we want to do that first
14:47:23 <stefw> yeah, but the milestone is further away
14:47:30 <dperpeet> so we don't have any nasty surprises later on
14:47:33 <stefw> eitherway, once we have a F23 milestone, we probably will have it there
14:47:40 <stefw> in addition for RHEL, the Atomic stuff is really the interesting part
14:47:46 <mvo_> right
14:48:06 <stefw> since the whole all-updates-offline for stock RHEL (not Atomic) is not likely to be super palatable for admins
14:48:33 <stefw> on Atomic, offline-updates are the only way, and that's a feature of the OS
14:48:35 <mvo_> ok, sorry for causing confusion here
14:48:39 <stefw> but for RHEL, people are used to live updates
14:48:47 <stefw> so the PackageKit offline updates is an interesting first round here
14:49:07 <stefw> but in the end it would be really nice to have the info needed from the package system to be able to do live updates for most OS updates
14:49:13 <stefw> but that's very far off.
14:49:19 <stefw> so to sumarize how i see it:
14:49:29 <stefw> * OSTree update UI is really compelling
14:49:55 <stefw> * PackageKit based offline UI is less compelling on servers, but provides base functionality none-the-less
14:50:40 <andreasn_> and live updates are possible, not just from the UI
14:50:44 <stefw> right
14:50:56 <petervo> well we can do it if want to
14:51:06 <stefw> yeah, but you have a system that will likely:
14:51:08 <stefw> a. fall over
14:51:08 <petervo> but it's not safe
14:51:10 <stefw> b. not be secure
14:51:17 <stefw> so it's kinda pointless
14:51:27 <andreasn_> yah
14:51:35 <stefw> currently, on at least yum based systems, you have to be intimate with your system to get it right
14:51:41 <stefw> to get live updates right
14:51:45 <stefw> and i mean *really* intimate
14:51:48 <stefw> like embarassingly
14:51:51 <andreasn_> hehe
14:52:24 <stefw> anyway, next topic?
14:53:48 <mvo_> #topic Patternfly update
14:54:04 <andreasn_> all right, so I started working on this. Have it in a branch right now
14:54:37 <andreasn_> css and fonts are updated. Dialogs currently breaks down for me
14:55:10 <andreasn_> not sure how to update bootstrap-select
14:55:21 <andreasn_> is this affected by stefw's package work?
14:55:28 <stefw> no
14:55:36 <stefw> don't look at me for blockers :)
14:55:39 <andreasn_> good
14:55:51 <andreasn_> just wanted to make sure
14:56:18 <mvo_> andreasn_, do you think you can make more progress?
14:56:26 <andreasn_> I think I can, yes
14:56:52 <stefw> andreasn_, do you want to work together to put the new files into the lib/ directory and link them appropriately?
14:57:06 <andreasn_> stefw: yeah, that would be great.
14:57:45 <andreasn_> I'm on PTO the rest of the week starting tomorrow, but we should have some time today or next week
14:58:16 <stefw> ok, today works for me
14:58:24 <andreasn_> I can push the branch after the meeting
14:59:24 <andreasn_> so yeah, that's it for that I think
15:00:38 <mvo_> #topic Storage refresh and storaged
15:01:03 <stefw> the guys working on the new storaged promised to have it in fedora soon
15:01:17 <andreasn_> \o/
15:01:21 <stefw> and fabiand is working to document some iSCSI use cases and API to add to it
15:01:24 <andreasn_> who's working on that in the end?
15:01:33 <stefw> jsafrane and friends
15:01:36 <andreasn_> nice
15:01:48 <stefw> so ... we discussed about reworking our storage to use the new storaged
15:02:02 <stefw> we should probably think about doing that work soon
15:02:21 <stefw> mvo_ what do you think? is this something you are interested in? i remember you planned it out a bit.
15:02:31 <stefw> this is just about changing the implementation, i think, not the designs
15:02:56 <mvo_> yes, I am quite interested
15:03:02 <mvo_> not sure about the schedule, though
15:03:34 <mvo_> i was going to concentrate on F22
15:03:41 <stefw> hmmm, yes, good point
15:03:42 <mvo_> but that should be over soonish as well
15:03:46 <stefw> right
15:04:41 <mvo_> so I would postpone that a bit
15:04:55 <mvo_> at least until I am out of the metrics stuff
15:05:04 * mvo_ is a really bad multitasker
15:05:58 <stefw> no worries
15:06:10 <stefw> i'm a bit worried about blocking fabiand and jsafrane's work, but i think we can work around that
15:06:29 <stefw> in particular, they can start using the new storaged for prototyping iSCSI work even when we're using the old one
15:06:37 <stefw> as long as we promise to resolve it before their code gets merged
15:06:53 <stefw> anyway, this is all thinking ahead
15:07:00 <stefw> the iSCSI code doesn't exist yet
15:07:08 <stefw> we're in the use case and API phase
15:07:08 <mvo_> yes, let's see in two weeks
15:07:28 <mvo_> so udisks-plus-plugins is the new storaged?
15:07:46 <stefw> yeah, mostly
15:08:01 <mvo_> ok
15:08:03 <stefw> definitely delaying on this for a few weeks is appropriate
15:08:07 <mvo_> and it is called "storaged"? :)
15:08:16 <stefw> yeah, mostly :)
15:08:21 <mvo_> :)
15:08:31 <mvo_> ok, yep, let's see.
15:08:45 <mvo_> but yeah, let's not ruin the momentum.
15:09:16 <stefw> right
15:09:46 <mvo_> open floor?
15:09:49 <stefw> y
15:09:57 <mvo_> #topic open floor
15:10:33 <dperpeet> subscriptions: who wants to test around a bit tomorrow/Wednesday? I was thinking of petervo, so he can look at updates as well
15:10:54 <andreasn_> I would love to test when I'm back from vacation
15:10:57 <mvo_> sure
15:10:58 <petervo> sure
15:11:30 <dperpeet> I've been working on the script to set everything up on a clean rhel vm
15:11:38 <dperpeet> so hassle should be minimal
15:11:46 <dperpeet> I'll ask again here when I'm ready
15:11:47 <petervo> nice
15:11:47 <andreasn_> nice
15:12:21 <mvo_> ok!
15:12:26 <mvo_> done?
15:12:40 <stefw> \o/
15:12:42 <andreasn_> I think so
15:12:56 <mvo_> #endmeeting