15:00:36 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-04-28)
15:00:36 <zodbot> Meeting started Tue May  5 15:00:36 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:36 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
15:00:36 <sgallagh> #topic roll call
15:00:36 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:00:52 * danofsatx is actually here today!
15:00:56 <nirik> morning.
15:00:58 <danofsatx> Woot! \o/
15:01:02 <sgallagh> .hello sgallagh
15:01:03 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:41 <mitr> Hello
15:01:51 <danofsatx> .hello dmossor
15:01:52 <zodbot> danofsatx: dmossor 'Dan Mossor' <danofsatx@gmail.com>
15:02:14 <mizmo> .hello duffy
15:02:15 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
15:03:47 <sgallagh> OK, we have quorum at least.
15:03:54 <sgallagh> #topic Agenda
15:04:08 <sgallagh> I didn't send out an agenda yet, sorry about that.
15:04:33 <sgallagh> From last week, we were planning on following up on two topics; the API/ABI assertions and offline updates
15:05:09 <sgallagh> Since mizmo is here this week, I was thinking we should also ask for a Websites and Design Team status (and whether they need anything from us for Final)
15:05:26 <adamw> ahoy
15:05:28 <sgallagh> #info Agenda Item: Websites and Design Team Update
15:05:33 <sgallagh> #info Agenda Item: Offline Updates
15:05:39 <sgallagh> #undo
15:05:39 <zodbot> Removing item from minutes: INFO by sgallagh at 15:05:33 : Agenda Item: Offline Updates
15:05:47 <sgallagh> #info Agenda Item: Offline/Online Updates
15:06:04 <mizmo> (i don't have an update right now, we're still working on the new websites forf edora that are getting launched so the getfedora.org updates are a bit backburner atm) :(
15:06:07 <sgallagh> #info Agenda Item: API/ABI Guarantees
15:06:28 <sgallagh> Any other agenda items for this week?
15:07:48 <sgallagh> Sounds like no.
15:07:50 * adamw has nothing.
15:07:58 <sgallagh> #topic Websites and Design Team Update
15:08:14 <mizmo> no update, see ^^
15:08:21 <sgallagh> #info No update right now, Design Team is still working on the new websites for fedora that are getting launched so the getfedora.org updates are a bit backburner atm
15:08:41 <mizmo> i think the main thing we were looking to do was update the quotes
15:08:43 <sgallagh> mizmo: Yup, just wanted to capture it correctly in the minutes
15:08:49 <mizmo> and add a logo for cockpit
15:08:56 <mizmo> if i'm forgetting something lemme know
15:09:10 <sgallagh> #info Websites team wants to update the quotes and add a logo for Cockpit
15:09:17 <sgallagh> mizmo: Will do, thanks!
15:09:21 <nirik> perhaps add something abotu the db role?
15:09:37 <mizmo> i can do that, but i definitely need some help writing copy for it
15:10:07 <mizmo> can anyone help?
15:10:28 <sgallagh> mizmo: Sure, I can help with that.
15:10:37 <mizmo> \o/
15:10:39 <mizmo> thanks
15:10:41 <sgallagh> #action sgallagh to assist with writing copy for the Database Server Role
15:10:59 <mizmo> #info getfedora.org/server to be updated with new quotes, cockpit logo, and db role info
15:11:31 <sgallagh> mizmo: Anything else?
15:14:16 <sgallagh> /me assumes no.
15:14:48 <mizmo> noppers sorry
15:14:54 <sgallagh> stefw brought this up last week. He was going to start a discussion on the list, but that didn't happen.
15:15:08 <nirik> it's an anoying problem. ;)
15:15:34 <sgallagh> I've been looking into the PackageKit/systemd mechanism a bit myself and I'm experimenting with it today.
15:15:56 <sgallagh> I think we may be able to do "warm" updates as simo suggested by dropping to the system-updates.target and then bringing the default target back up.
15:16:12 <nirik> I'm not sure that really gets that much tho, does it?
15:16:18 <sgallagh> #action sgallagh to test "warm" updates and report back.
15:16:21 <nirik> over just doing a reboot/update cycle?
15:16:43 <sgallagh> nirik: It really helps with many of the servers with extremely long POST cycles.
15:16:49 <mitr> nirik: It skips the possibly very long in-BIOS self test, though possibly at the cost of some robustness
15:16:51 <sgallagh> And also for any that have disk encryption
15:17:08 <nirik> ok. I guess...
15:17:56 <nirik> I think there will definitely be a chunk of people who want to do online updates still...
15:18:28 <sgallagh> nirik: Well, we're not stopping them from using DNF.
15:18:48 <mitr> Fundamentally I think the right thing to do is to default to off-line, but have mechanisms/heuristics that allow on-line updates in known safe cases, and then aim to extend the on-line share over time.
15:18:48 <nirik> I know. Anyhow, look forward to hearing your results.
15:19:23 <nirik> mitr: yeah, with a option to disable offline if you want to take the risks.
15:19:48 <sgallagh> nirik: That option is "ssh and dnf"
15:19:52 <mitr> Sure, the underlying tools are always available
15:19:57 <sgallagh> We're mostly talking about the Cockpit approach right now
15:20:18 <nirik> sgallagh: yes, but what I am saying is we should make sure that people can choose to opt-out of a off-line or warm approach.
15:20:48 <sgallagh> nirik: I think we're talking past each other.
15:20:54 <nirik> probibly. sorry. ;)
15:21:15 <sgallagh> I don't believe that such an option makes sense *in Cockpit*, which is where we should keep things as simple as possible.
15:21:39 <sgallagh> For those people who are willing to accept those risks, SSH (or Cockpit's terminal page) should be their tool.
15:21:45 <nirik> agreed. if this is just a 'apply updates warm/off-line' in cockpit that people can just choose to not push thats fine
15:22:02 <nirik> I meant more if we extend it with a timer unit or cron job.
15:22:03 <sgallagh> OK, I think we're on the same page now :)
15:22:32 <sgallagh> nirik: My opinion would be that automatic updates should always be opt-in
15:22:40 <nirik> +1
15:23:17 <nirik> anyhow, we can move on
15:23:26 <sgallagh> OK.
15:24:07 <sgallagh> We discussed this a bit last week, but wanted everyone to have a week to ruminate on it before we made any plans.
15:24:11 <sgallagh> A week has passed :)
15:24:58 <nirik> I think it's a good plan, but we will have to choose carefully what packages/set we want to try and include.
15:25:22 <nirik> also communicate with package maintainers of those...
15:25:27 <sgallagh> /me nods
15:26:11 <sgallagh> I'd like to say that the approach we should take would be to carefully select a very limited set of APIs to start with and slowly grow that over time if appropriate.
15:26:22 <nirik> yeah, sounds sane
15:26:27 <mitr> Yes.
15:26:46 <sgallagh> Like starting with "kernel", "glibc" and probably the systemd APIs.
15:27:28 <mitr> Presumably the roles should have some kind of ABI-stable way of being used
15:27:53 <sgallagh> mitr: I'm not sure that necessarily has to be true.
15:28:27 <mitr> In some cases that ABI may be external-facing rather than local to the machine
15:28:31 <sgallagh> I think that we may want to consider stating that APIs *provided* by the roles have such-and-such guarantee, but what they use under the hood doesn't necessarily need to be publicly stable
15:28:51 <sgallagh> Or maybe I misunderstood your first sentence.
15:29:05 <mitr> Right, only the external facilities provided by the role; not making any promises about the implementatino of the role.
15:29:06 <sgallagh> I may just have agreed with you, on re-reading.
15:30:03 <mitr> E.g. if someone deploys the DB role, they should be told what is the supported way to access the DB and how long can they expect a client accessing the DB to keep working without having to be updated/replaced/rewritten.
15:30:30 <sgallagh> mitr: Right, makes sense. And in the case of PostgreSQL, that's fairly easy to do, as they have a pretty strong API guarantee upstream.
15:31:00 <mitr> (Or alternatively not-quite-an-ABI, that they should always access the DB through $client_program, which may need to be updated but has a frozen external interface; )
15:31:25 <adamw> so if our 'stable API' is just a list of upstream things with stable APIs, what are we providing?
15:31:31 <adamw> (kernel, glibc, systemd, pgsql)
15:32:08 <sgallagh> adamw: Well, as noted in the beginning, I'm talking about starting small and building from there.
15:32:24 <sgallagh> In part with the documentation efforts and the making comfortable of the potential userbase.
15:32:30 <mitr> adamw: 1) to users, a single list instead of having to ask every upstream separately, 2) to everyone, hopefully testing and validation, 3) to upstreams, an user explicitly interested in tability and hopefully willing to help out
15:32:48 <sgallagh> mitr++
15:32:48 <zodbot> sgallagh: Karma for mitr changed to 1:  https://badges.fedoraproject.org/badge/macaron-cookie-i
15:34:26 <sgallagh> adamw: Going forward, we *want* this to grow, but it's too big a task to try to attack all at once.
15:34:53 <sgallagh> /me would expect adamw to be an expert on the subject of "taking on enormous tasks"
15:35:13 <adamw> yes, but so far it sounds like more or less no task, unless someone's volunteering for the 'testing and validation'
15:35:27 <sgallagh> adamw: Yeah, we are. That also came up last week.
15:35:52 <sgallagh> For one such concrete example, I'm trying to drum up support for building a taskotron API comparison tool.
15:37:14 <sgallagh> In the general case, I want to make it so that nothing gets autokarma'd with a public backwards-incompatible change, and that nothing on our stable list can be pushed with such a change without high-level intervention.
15:38:20 <sgallagh> It sounds like some tools like libabigail can help us with this.
15:38:51 <sgallagh> D-BUS stuff will be more "interesting" of course; and will likely require a real CI setup to test.
15:39:04 <adamw> yes, i was here last week
15:39:11 <adamw> no need to rehash
15:40:07 <sgallagh> OK
15:40:49 <sgallagh> So yes. Someone will have to do some of the testing and validation, and also we are going to gather the documentation together (and we'll need to have a plan for maintaining its curation).
15:41:08 <sgallagh> Since this is mostly going to be the adaptation of upstream docs, I *hope* we can automate that as much as possible.
15:42:52 <nirik> abicheck should/can help too with testing
15:43:13 <sgallagh> #info abicheck is another tool to look into
15:44:36 <sgallagh> OK, I don't have much else here at the moment.
15:44:45 <sgallagh> Shall we move to Open Floor?
15:45:44 <sgallagh> ok then
15:45:48 <sgallagh> #topic Open Floor
15:46:55 <sgallagh> Something I thought of during the meeting: Do we want to reconsider the decision not to use containers for the Roles in F23? The primary reason we are not doing so today was the lack of non-x86_64 support, but that's changing.
15:47:39 <sgallagh> More directly: would we as a group have a problem with some Roles only working on certain architectures?
15:47:52 <mitr> I’m tempted to treat that as an implementation detail of the role.  Would containers as such give a specific benefit (easier rollback perhaps)?
15:48:12 <sgallagh> mitr: Easier rollback and potentially safer upgrades as well.
15:48:21 <mitr> ok
15:48:25 <sgallagh> (Don't need to update the container at the same time as the host OS)
15:48:45 <mitr> I have no problem with dropping ix86 and arm32; not sure about arm64
15:48:57 <sgallagh> arm32 now has docker support, actually
15:49:32 <sgallagh> Only i686 of the primary arches is lacking support.
15:49:51 <sgallagh> aarch64 is going to be getting upstream support; I'm unclear if that has yet landed.
15:51:09 <sgallagh> /me is slightly tempted to suggest dropping i686 as a Fedora Server install target as well...
15:52:00 <adamw> eh, i suspect we'd get the 'using old hardware crowd' up in arms
15:52:23 <sgallagh> adamw: They can install from the i686 netinstall if they really want to.
15:52:51 <sgallagh> s/netinstall/generic netinstall/
15:54:03 <adamw> ...which still doesn't exist...
15:54:08 <sgallagh> Let's table that particular discussion for today and I'll bring it up on the mailing list.
15:55:18 <sgallagh> adamw: Oh. Damn. I thought Dennis did that pre-Alpha. Well, we'll worry about it in F23, I guess.
15:55:29 <adamw> sure.
15:55:31 <sgallagh> Way too late to deal with it for F22
15:56:14 <sgallagh> OK, so anything else for Open Floor? If not, I'll give you back a few minutes of your lives.
15:58:26 <sgallagh> Thanks for coming, folks.
15:58:34 <sgallagh> #endmeeting