15:00:08 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-04-28)
15:00:08 <zodbot> Meeting started Tue Apr 28 15:00:08 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:08 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
15:00:08 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:00:08 <sgallagh> #topic roll call
15:00:15 <nirik> morning
15:01:04 * nirik grabs some more coffee real quick, back in a min
15:01:51 <adamw> .hello adamwill
15:01:52 <zodbot> adamw: adamwill 'Adam Williamson' <adamw+fedora@happyassassin.net>
15:02:32 <jonmasters_> .hello jonmasters
15:02:33 <zodbot> jonmasters_: Sorry, but you don't exist
15:02:38 <jonmasters_> lolcano
15:02:51 <sgallagh> jonmasters_: Greetings. You need to use your FAS account for that to work :)
15:03:09 <sgallagh> And welcome! Always nice to see a new face.
15:03:14 <jonmasters_> well, I'm here, so meh. Also, P.S. I *EXIST*
15:03:40 <jonmasters_> (I consume coffee therefore I am)
15:03:45 * randomuser sits quietly in the back
15:04:08 <randomuser> coffee intake is low still, I may not exist yet
15:05:01 <sgallagh> /me wonders whether any of the rest of the SIG is coming
15:06:10 <sgallagh> OK, I guess we'll get started and see who turns up.
15:06:15 <sgallagh> #topic Agenda
15:06:21 <sgallagh> #info Agenda Item: F23 Planning
15:06:30 <sgallagh> #link https://lists.fedoraproject.org/pipermail/server/2015-April/001842.html
15:06:38 <sgallagh> #undo
15:06:38 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x841c250>
15:06:49 <sgallagh> (That should be done in the topic...)
15:07:08 <sgallagh> Other items for this week's agenda?
15:07:08 <stefw> .hello stefw
15:07:10 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
15:07:30 <sgallagh> jonmasters_: I'm guessing that your presence indicates an interest in ARM/AARCH64 functionality.
15:08:21 * adamw got nothin'
15:08:41 <sgallagh> adamw: Things are good for F22 Final?
15:08:47 <adamw> i didn't say that. :P
15:08:52 <adamw> we do TC1 today
15:08:58 <adamw> so...we'll find out?
15:09:09 <sgallagh> OK, nothing specific for today, then,
15:09:14 <sgallagh> ok, let's proceed.
15:09:19 <sgallagh> #topic F23 Planning
15:09:40 <sgallagh> Hey, look at that! We're past F22 Beta, so it's time to start planning our next cycle.
15:09:58 <sgallagh> I've sent out some thoughts on this matter to the mailing list:
15:10:02 <sgallagh> #link https://lists.fedoraproject.org/pipermail/server/2015-April/001842.html
15:10:29 <nirik> I think you have a nice idea there...
15:10:37 <sgallagh> nirik: ... but/
15:10:40 <sgallagh> ?
15:10:53 <nirik> one other prong of this could be to also make sure fedup is rock solid, so upgrades aren't a big deal.
15:12:02 <nirik> as for the abi, it's a bit chicken and egg... if we make it will they come?
15:12:06 <sgallagh> nirik: fedup is already pretty solid *when used only with Fedora repos*. Solving the emphasized part of that...
15:12:35 <sgallagh> nirik: Well, I think figuring out what ABI stuff we want to consider stable and advertise is a useful step no matter what.
15:12:42 <nirik> sure. agree.
15:12:54 <nirik> I like this idea about 10000x better than us making multiple distros. ;)
15:13:12 <sgallagh> nirik: When did multiple distros come up?
15:13:31 <adamw> it's a reasonable thing to try, sure.
15:13:42 <nirik> well, thats basically what happens if we try and make different life cycles as far as I am concerned.
15:13:52 <nirik> if we have different repos of packages on different lifecycles.
15:14:00 <nirik> they really are not the same thing.
15:14:39 <sgallagh> nirik: Well, I'm not sure that's fundamentally different from supporting Fedora N and N-1, but let's not derail on that since we're trying to avoid it anyway :)
15:14:52 <nirik> sure, agreed.
15:15:29 <nirik> so then the questions become: whats in the compat circle and how long do we promise.
15:15:41 <adamw> and how hard do we promise it
15:15:47 <sgallagh> Another side-effect to this exercise is that it will help us get a handle on exactly what stuff we're shipping in the default configuration and may encourage us to help with some of the work to minimize dependenies.
15:15:58 <stefw> IMO, such an ABI guarantee starts off with documentation
15:16:09 <sgallagh> stefw++
15:16:09 <zodbot> sgallagh: Karma for stefw changed to 1:  https://badges.fedoraproject.org/badge/macaron-cookie-i
15:16:13 <stefw> of the interfaces themselves
15:16:23 <nirik> adamw: and that also flows into f23 critera. ;) "run this and make sure these abis have not changed" :)
15:16:40 <sgallagh> Most of the interfaces _have_ available documentation, but it's scattered all over the place.
15:16:56 <adamw> nirik: eh, it seems like a bad thing to try and handle through QA, it should be tooled.
15:16:58 <sgallagh> Some is installed with the packages, some is on the web, some is in add-on packages...
15:17:02 <stefw> right, bringing it together and saying "this here" is what we've deemed stable so far
15:17:03 <adamw> (as sgallagh suggested.)
15:17:28 <nirik> yes, right, I didn't mean it should be manual at all.
15:17:39 <sgallagh> Right, if we agree on this as a strategic move for F23, I'm going to put together a group of people to add taskotron functionality for this.
15:17:58 <randomuser> sgallagh, if someone can maintain a list of these places, I might be able to throw together tooling to automate it.. or taskotron can do it
15:17:59 <sgallagh> I believe there are some RHEL tools that we may be able to adapt for the purpose.
15:18:21 * randomuser is working on a buildbot thing vaguely parallel to taskotron
15:18:34 <sgallagh> randomuser: Well, in my opinion, one of the singular best things we could do is to build essentially a Fedora Developer Network site, similar to MSDN.
15:18:52 * randomuser nods
15:19:03 <sgallagh> Centralize everything we're supporting in a common place, even if that means converting some things from man/info to HTML
15:19:18 <bochecha> sgallagh, dodji has been working on libabigail for a while now, it includes an abidiff tool which is pretty handy and could be plugged into a taskotron test
15:19:24 <adamw> please, no more things vaguely parallel to taskotron, we have like four already.
15:19:31 <sgallagh> And since our deployments are primarily headless, the web seems like an obvious choice.
15:19:34 <randomuser> there are some existing stuff to convert from man/info to html, not too hard, just nobody has cared to do it
15:19:50 <sgallagh> bochecha: Yeah, that would be fantastic.
15:20:03 <stefw> C ABIs are a minor part of the story, IMO
15:20:06 <bochecha> sgallagh, I keep telling him to go and talk to the taskotron folks about it :)
15:20:14 <sgallagh> #info libabigail includes an abidiff tool which is pretty handy and could be plugged into a taskotron test
15:20:30 <stefw> things like file format APIs, DBus APIs, REST APIs and so on are things we need to figure out how to check, document, etc.
15:20:31 <sgallagh> stefw: Yes, agreed. We also need to be talking about D-BUS as well
15:20:34 <adamw> sgallagh: i suspect a *DN site is a lot more work to maintain than it might like like
15:20:41 <adamw> don't want to be biting off more than we can chew
15:20:47 <adamw> s/like like/look like/
15:20:49 <sgallagh> adamw: Well, we have the Fedora Docs site
15:21:01 <sgallagh> We can probably try to just dump more content there
15:21:19 <adamw> sgallagh: where you will notice that for each release, teh number of manuals gets smaller, because we have more content than we can keep updated...
15:21:34 <sgallagh> adamw: True enough
15:21:40 <simo> adamw: what is a *DN site ?
15:21:55 <adamw> simo: "Fedora Developer Network" or whatever
15:21:56 <sgallagh> But if we have the tooling I'm also proposing, we at least can start auto-generating bugs to let us know which parts need updating
15:22:12 <simo> btw sorry for being late ppl
15:22:21 <sgallagh> simo: No worries.
15:22:29 <simo> sgallagh: have you already discussed API/ABI stability ?
15:22:44 <sgallagh> simo: Ongoing :)
15:23:10 <simo> sgallagh: the problem I see with that is that unfortunately there are way too many upstreams (and the number is growing) that do not care
15:23:19 <simo> sgallagh: which is why people want LTS releases
15:23:20 <sgallagh> simo: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-04-28/fedora-meeting-1.2015-04-28-15.00.log.txt
15:23:26 <simo> so they get to stay on 'older' versions
15:23:53 <sgallagh> simo: Well, part of this effort would be hand-picking the set of APIs we want to consider stable
15:24:00 <sgallagh> This should *not* be everything we are currently shipping.
15:24:18 <simo> sgallagh: the problem is "dependencies"
15:24:36 <sgallagh> simo: We don't have to assert that the dependencies have stable API
15:24:47 <sgallagh> Only that they continue to work under the hood to support the stable APIs
15:24:49 <simo> as soon as a library has a bigh dependency graph if you block it, you may end up blocking a large subtree of packages
15:25:28 <sgallagh> For example, under no circumstances should "boost" be on the supported list :)
15:25:42 <simo> I think we end up conflicting with our "First" mission if we try to block packages in new releases on API stability promises
15:25:42 <stefw> i don't think the plan is to block updates to packages with stable API/ABI
15:25:51 <sgallagh> simo: I said nothing about "blocking"
15:25:56 <simo> ok then what ?
15:26:00 <sgallagh> I said the plan was to ensure that we maintain compatibility.
15:26:07 <simo> how ?
15:26:15 <sgallagh> This might mean in limited cases carrying a compat lib or D-BUS interface.
15:26:27 <sgallagh> But again, only for a set of extremely high-value APIs
15:26:32 <sgallagh> (like systemd, glibc, etc)
15:26:46 <simo> well if we are ok introducing multiple versions of packages ... well we might get into another can of worms
15:26:54 <nirik> its all worms. ;)
15:26:54 <simo> but it is potentially a little bit more feasible
15:27:16 <simo> sgallagh: glibc never breaks API/ABIs
15:27:21 <simo> not consiously at least
15:27:29 <sgallagh> Well, the idea would be that we should do something similar to RHEL and decide that API A, B and C we will guarantee for N releases (maybe that number is 2)
15:27:35 <simo> otoh systemd seem still a little bit rough on that side
15:27:39 <sgallagh> simo: Right, which makes it an easy choice :)
15:27:41 <adamw> do we have plans to finish off our *first* set of plans before jumping into new ones, btw? as of f22 the role stuff is still kind of a curate's egg, as (afaik) we still don't have a particularly nice deployment system.
15:27:59 <sgallagh> simo: systemd has a subset of stable APIs and some noted unstable ones.
15:28:07 <adamw> so, i hope this isn't a case where we run onto the next shiny before finishing the first shiny
15:28:17 <sgallagh> adamw: We actually just got a GSoC student to work on that part of it.
15:28:20 <simo> adamw: I think they go hand in hand
15:28:31 <sgallagh> (The Cockpit deployment of roles)
15:28:36 <simo> adamw: stable APIs help us having stable roles that can be upgraded easily
15:29:56 <stefw> hmmm, not sure i would make that leap
15:29:57 <simo> .hello simo
15:29:57 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
15:30:08 <stefw> i mean stable roles are because the roles upgrade well
15:30:12 <sgallagh> simo: That may be an oversimplification. The roles themselves tend to be fairly complicated. But I'm still looking into whether we will be able in F23 or F24 to move them to a more containerized solution so they can carry their own deps and sidestep this.
15:30:14 <stefw> not necessarily because of stable system APIs
15:30:39 <simo> sgallagh: that's not necessarily going to be less work, rather the opposite
15:30:51 <simo> stefw: well it is all connected
15:31:09 <simo> stefw: if stuff don't break on the lower level it is easier to keep stuff working on the upper
15:31:19 <stefw> yeah, but having stable roles is a whole lot easier than having stable system apis
15:31:27 <simo> for example building CI tools that allows us to detect early when a change in rawhide will break roles
15:31:45 <simo> stefw: I don't disagree
15:31:52 <sgallagh> stefw: Not always. We had a mess dealing with Tomcat changing out from under FreeIPA...
15:32:06 <simo> and as I noted part of Fedora is to be "First" which means taking the pain of new breakage too
15:32:15 <sgallagh> But yes, as simo says I think improving the tooling to detect this stuff early is key
15:32:34 <simo> so perhaps for F23/24 we need to concentrate on the detection tooling
15:32:48 <simo> that will give us data (if done correctly) that will help us do 2 things
15:33:03 <simo> 1) be able to define a safe subset of projects that tend to care about API stability
15:33:13 <simo> 2) provide us with insights on how to deal with the rest
15:34:05 <simo> and maybe 3) help us put pressure on 'the bad actors'
15:35:13 <sgallagh> So, just to interject: I'm not hearing anyone disagree that the steps proposed of improving the detection tooling and sorting through which APIs are known to be compatibility-conscious is a bad idea. Maybe the long-term vision is a little cloudy, but is there any opposition to taking these steps? (Is there concern that it won't have any positive effect?)
15:35:55 <stefw> i think effort to have comprehensive high level apis for the system is a good plan
15:36:03 <stefw> i'm less sure about starting to getinto the whole stability process
15:36:07 <simo> I guess the only concern is: who is going to do this, and what will be left behind ?
15:37:03 * nirik thinks it's worth persuing, but I don't think we should all vote on it as a f23 change today. It was just sent out to the list and not everyone has had time to think about it or comment.
15:37:31 <sgallagh> Well, this isn't necessarily a Change so much as a strategic direction from which we will build our set of Changes
15:37:34 <simo> wfm
15:37:49 <simo> sgallagh: I agree on the direction anyway
15:37:55 <sgallagh> So certainly we shouldn't be filing Changes on it yet :)
15:38:04 <simo> we will need to discuss much better what we can actually do and what we aspire to
15:38:08 <sgallagh> /me nods
15:39:13 <nirik> right. yep.
15:40:02 <sgallagh> OK, so I'm going to move ahead with scrounging up interest then.
15:40:23 <simo> GO
15:40:29 <sgallagh> And we'll try to figure out concrete steps for next week's meeting.
15:40:50 <sgallagh> #info Formulate concrete plans at next week's Server SIG meeting
15:40:51 <nirik> sounds great
15:41:21 <sgallagh> Any other ideas for F23 that folks want to bring up?
15:41:32 <stefw> operating systemu pdates
15:41:38 <stefw> maintenance free operating system updates
15:41:43 <stefw> i need to write something up
15:41:57 <sgallagh> stefw: From the Cockpit side of things?
15:41:58 <stefw> as in security updates
15:42:07 <stefw> but at present we don't have a way to update the system without intimate knowledge of the rpms and what they do, what to restart, etc.
15:42:22 <stefw> either we bring in an offline update system
15:42:41 <stefw> or we figure out how to make online rpm based updates be quantifiable
15:42:44 <sgallagh> Right, which we can do with PackageKit today, through Cockpit.
15:42:51 <stefw> Cockpit doesn't do PackageKit
15:42:51 <sgallagh> (well, *could* rather than *can*)
15:42:56 <stefw> at least not yet
15:43:06 <stefw> PackageKit has dependency problems at present that make it hard to use on servers
15:43:08 <stefw> such as bringing in X
15:43:11 <stefw> but i think that's being worked on
15:43:18 <stefw> in general we need to discuss whether offline updates are the way to go
15:43:28 <stefw> or whether we can make online updates robust with regards to:
15:43:30 <stefw> interruption of service
15:43:31 <sgallagh> stefw: Hmm.. we have PackageKit on the default Server install I thought
15:43:40 <sgallagh> Yes, we do
15:43:42 <stefw> restarting everything that is vulnerable
15:43:51 <stefw> i think you have Package kit libraries
15:43:53 <stefw> but not the entire system
15:43:58 <stefw> although i may be mistaken
15:44:01 <sgallagh> rpm -q PackageKit
15:44:01 <sgallagh> PackageKit-1.0.5-2.fc22.x86_64
15:44:05 <stefw> oh nice
15:44:21 <simo> stefw: for a server I wopuld strongly oppose offline updates
15:44:22 <stefw> well, i guess the question is whether we bless packagekit for use on servers, make it work, test it, and so on
15:44:33 <sgallagh> Though it appears to be set disabled by default, but that's easy to fix.
15:44:34 <simo> at least if offline means actual reboot
15:44:47 <stefw> right ... i don't like offline updates either
15:44:54 <simo> if it means going to "level 6", apply updates and then restart all software then it *may* work
15:44:58 <stefw> but we have a completely non-robust system for online updates
15:45:09 <stefw> where you basically have to be sleeping with rpms that get updated to know them well enough
15:45:12 <stefw> in order to know what to restart
15:45:17 <stefw> or whether you're actually secure after doing an update
15:45:17 <simo> the reason is that while a laptop these days may boot pretty fast, I have machines that takes *minutes* to boot
15:45:23 <simo> it is not acceptable
15:45:24 <stefw> whether clients of the server got killed etc...
15:45:38 <stefw> our online update system is a complete crapshoot
15:45:41 <nirik> dnf has a plugin to tell you what needs restart...
15:45:42 <stefw> so either we fix it
15:45:45 <nirik> but yeah
15:45:47 <sgallagh> simo: Machines with a really long POST you mean?
15:45:51 <stefw> well if we can further develop that plugin
15:45:58 <sgallagh> nirik: That's a good start, but it's not perfect.
15:45:58 <simo> sgallagh: yes
15:46:02 <stefw> the dnf plugin, so that it detects libraries and dependencies, that would be really cool
15:46:16 <stefw> in addition predicting which  services willb reak during the update
15:46:18 <stefw> and for how long
15:46:24 <simo> stefw: I would go the direction of the plugin indeed
15:46:36 <simo> stefw: however that one detects only direct dependencies
15:46:43 <nirik> it already exists, but you still run into corner cases.
15:46:47 <stefw> right, it would obviously need tons of work
15:46:48 <simo> this like IPC/RPC won't be detected
15:46:51 <nirik> and kernel, glibc, etc
15:46:55 <stefw> and would need to produce a list of systemd services that should be restarted
15:46:57 <stefw> and/or cgroups
15:47:04 <stefw> something like that
15:47:05 <simo> things like kdbus would really help here
15:47:20 <sgallagh> stefw: Well, the %post script of most services triggers their own restart when it's safe.
15:47:22 <simo> at least for the system message bus problem
15:47:26 <stefw> heh heh
15:47:26 <sgallagh> But this doesn't help when you update glibc...
15:47:37 <nirik> it uses a package called 'tacer'
15:47:39 <nirik> tracer
15:47:40 <simo> which is not big for the server case yet, but system bus usage is growing on servers too
15:47:41 <stefw> the %post scripts just go wild
15:48:10 <simo> sgallagh: well proper ordering of the updates would probably help 90% of the cases
15:48:32 <sgallagh> simo: Ordering of the updates may not be a solvable problem.
15:48:37 <simo> if rpm install is ordered base on actual library dependency you'd get glibc basically always updated first
15:48:56 <simo> but then it would only be beneficial to other software you are upgrading at the same time
15:48:56 <sgallagh> simo: Which still doesn't help for services that aren't updated as part of the transaction
15:48:58 <nirik> while it's nice to talk about the single server case... in the end if you are depending on one server for anything you aren't going to have 100% availability
15:49:08 <simo> you may still need to reboot running software
15:49:14 <stefw> i hate to say it but: Fedora Server is single server case
15:49:19 <simo> but at least you wouldn't need to restart some daemons twice
15:49:26 <stefw> cloud and microservices already use offline updates
15:49:27 <nirik> stefw: currently at least yeah
15:49:29 <stefw> imo that's out of scope
15:49:42 <sgallagh> stefw: What is out of scope, exactly?
15:49:53 <stefw> expecting all services on a Fedora Server to have failover
15:49:58 <stefw> and be written in a distributed manner
15:50:05 <sgallagh> yeah, that's implausible at best.
15:50:20 <simo> I do not think that is a problem
15:50:28 <simo> we just need to make the update "safer", not perfect
15:50:34 <simo> we have ways to improve it
15:50:38 <stefw> we need to make it perfect
15:50:42 <stefw> and or fail safe
15:50:44 <simo> and at least servers have less intricate depdnencies
15:50:53 <stefw> otherwise you're vulnerable
15:50:53 <stefw> after an update
15:50:53 <stefw> not acceptable
15:50:57 <sgallagh> stefw: Well, I doubt it's possible to make it "perfect" without offline updates.
15:50:59 <nirik> well, online will never be 100% safe
15:51:02 <nirik> /perfect
15:51:03 <stefw> if the fail safe is to reboot the system (when you're not sure you can restart everything)
15:51:05 <sgallagh> The question is whether 90% is good enough
15:51:25 <stefw> i would say no
15:51:42 <simo> stefw: so from the pov of getting all software that has a library dependency restarted if the library is updated I think we can get it 100% done
15:51:44 <stefw> if the user has only used Fedora Server software
15:51:53 <stefw> then it should be reliable
15:51:54 <simo> as long as it is stuff started via init scripts
15:52:11 <simo> we can a) find all processes using the older library easilyu
15:52:16 <simo> we can find the executable
15:52:33 <simo> we can find in which unit it is running (I think via cgroups or other systemd magic)
15:52:33 <nirik> and tracer tells you a 'helper' on restarting
15:52:43 <simo> hence we can find which unit file to restart
15:52:44 <sgallagh> But can we know if it's safe to restart any particular service? Or that restarting it out of order won't break other things?
15:52:55 <simo> we can collect all unit files we discovered
15:53:00 <stefw> two separate things
15:53:03 <simo> and at the end of the dnf transacation restart them all
15:53:10 <stefw> we could say that "the system must not be vulnerable"
15:53:18 <simo> and systemd takes care of starting them in the right order dependency wise
15:53:21 <stefw> however do best effort on "system service interrupted"
15:53:32 <stefw> in other words the scecond one may not need to perfect
15:53:39 <simo> if you are upgrading stuff it is ok to restart services
15:53:49 <simo> if you do not want that you can disable our dnf plugin
15:53:56 <simo> and you're back to manual restarts
15:54:11 <sgallagh> Still, glibc and systemd and kernel are going to be much easier to resolve with a reboot than a service restart.
15:54:15 <nirik> sample tracer output: http://paste.fedoraproject.org/216299/36443143/
15:54:33 <simo> sgallagh: well on that I would really like to have an option in systemd to do a "soft-reboot"
15:54:38 <simo> kill all services
15:54:43 <simo> restart itself
15:54:50 <simo> restart all services as if you were just booted
15:54:52 <sgallagh> simo: Not going to happen. I've argued with them till I'm blue in the face for that feature.
15:54:54 <simo> it can be done
15:54:56 <sgallagh> Upstream refuses.
15:55:10 <simo> although we may want to wait for kdbus to do it  a better way
15:55:13 <sgallagh> As an aside, I'd still like us to get PackageKit in shape for this. We should be relying on D-BUS services for as much as possible.
15:55:17 <stefw> simo, why wouldn't you use kexec in that case?
15:55:17 <simo> sgallagh: why do they refuse ?
15:55:24 <simo> stefw: we could indeed
15:55:30 <sgallagh> Rather than necessarily DNF API
15:55:34 <simo> but I am not sure it is safe on all hardware
15:56:05 <simo> sgallagh: if packagekit can be more server oriented sure
15:56:16 <simo> so far I always ditched it after a short try on servers
15:56:24 <simo> seem too desktop oriented in its development priorities
15:56:25 <sgallagh> simo: It basically boils down to "It's not 100% safe, so we're not going to add it and encourage people not to use the 100% safe approach)
15:56:34 <simo> sgallagh: what is not safe ?
15:56:58 <sgallagh> simo: I'm not going to reiterate their argument if you don't mind. It makes me angry and it's fairly nonsensical.
15:57:01 <stefw> i wonder if kexec fall back to a reboot if it fails?
15:57:05 <simo> is there an explanation somewhere of what are the issues ?
15:57:17 <simo> stefw: the problem is you may not know it really failed
15:57:24 <stefw> yeah i guess not
15:57:26 <simo> stefw: what if some HW just misbehaves
15:57:26 <stefw> some random piece of shit hardware
15:57:40 <simo> sgallagh: just point me at a writeup
15:57:50 <sgallagh> simo: The short version is that on anything but a freshly booted system, there's no guarantee that the system is in a known-good starting state to perform the transaction.
15:58:06 <sgallagh> Memory may be nearly exhausted, filesystems may have been unmounted, etc.
15:58:13 <stefw> systemd can restart itself ... wouldn't the same problems apply there?
15:58:17 <sgallagh> simo: There isn't one. It was verbal.
15:58:37 <simo> ok then it is inconclusive
15:58:58 <simo> I think we should discuss this again once kdbus is in
15:59:10 <simo> I suspect a big deal is the system message bus restarting is flakey
15:59:11 <sgallagh> simo: Frankly, I can't bring myself to continue the conversation, so if you want to pick it up with them, I'd appreciate it.
16:00:28 <sgallagh> We're coming up on the hour. Final thoughts?
16:01:54 * nirik has nothing
16:01:57 <stefw> i'll post something on the mailing list
16:01:57 <stefw> about thist
16:02:03 <stefw> briefly outlining the issue
16:02:16 <sgallagh> #action stefw to start a conversation about package/security updates on the mailing list
16:02:26 <sgallagh> stefw: Thanks. This is good stuff.
16:02:36 <simo> sgallagh: should we discuss a security repo
16:02:42 <simo> or push it anyway as FEdora Server SIG
16:02:57 <simo> I am quite unhappy at the speed of security packages reaching users in Fedora
16:03:03 <simo> and that is more important for servers imo
16:03:09 * nirik is -1000 to another repo
16:03:25 <sgallagh> simo: https://fedorahosted.org/rel-eng/ticket/5886#comment:25
16:03:32 <sgallagh> err, drop the comment. Sorry.
16:03:39 <simo> nirik: find a way to deliver them fast, I do not really care if it is another repo or something magic
16:03:45 <nirik> yeah, but thats only for urgent urgent stuff
16:04:10 <nirik> simo: well, we could do it today... have actual people test and upkarma the security updates we care about.
16:04:30 <simo> it still can take very long
16:04:51 <nirik> a few days, sure...
16:04:56 <simo> a separate repo can also have different dnf/yum cache times but you are against
16:04:58 <sgallagh> It might be worth considering whether security updates should automatically go to stable within three days unless it gets negkarma
16:05:03 <simo> a few days is alot these days
16:05:11 <nirik> it's a balancing act.
16:05:17 <nirik> on one hand you want the fixed package
16:05:27 <nirik> on the other hand you don't want a MORE broken package
16:05:35 <nirik> which has indeed happend.
16:05:41 <simo> I am ok for people to subscribe voluntarily to the express lane
16:05:49 <simo> I prefer a broken server than a vulnerable server myself
16:05:52 <nirik> enable updates-testing.
16:05:53 <sgallagh> nirik: A broken package usually isn't a security vulnerability! ;-)
16:05:55 <simo> other people may decide otherwise
16:06:07 <sgallagh> nirik: updates-testing is more than just security though
16:06:22 <simo> nirik: updates-testing means: "I am certain I have a broken server and security updates are still slow", no thanks
16:06:28 <sgallagh> But I think this is getting outside the Server purview.
16:06:36 <nirik> sgallagh: well, I thinking back on things like the dbus thing. :) "OH no, a major security problem, lets hurry and push this out! ASAP! NOW NOW NOW" "oh look, we broke dbus on all machines that applied our hasty update"
16:06:49 <sgallagh> For Server folks, I would expect anyone doing deployments to subscribe to the security package announce list
16:06:59 <nirik> simo: you can use the security plugin to just get those.
16:07:07 <nirik> at least with yum. I would hope dnf has a similar thing
16:07:15 <nirik> bodhi marks the security updates.
16:07:16 <sgallagh> nirik: I'm not aware of that plugin.
16:07:28 <simo> I switched to dnf
16:07:30 <sgallagh> Maybe that's something we should be advertising more widely?
16:07:48 <sgallagh> /me would voluntarily enable updates-testing for security issues too
16:08:02 <adamw> yum-cron has a setting to only do security updates too, iirc.
16:08:23 * adamw wonders what the status of yum-cron vs. dnf is...
16:08:43 <nirik> also fixing fedora-easy-karma would be nice (but we are working on that)
16:08:50 <sgallagh> nirik: Let's discuss this outside the meeting.
16:08:51 * randomuser is starting to wonder if there should be some documentation on writing a dnf plugin
16:09:00 <sgallagh> I think that would make for an excellent blog post...
16:09:38 <nirik> adamw: http://dnf.readthedocs.org/en/latest/automatic.html
16:10:19 <adamw> nirik: let me guess, there is no kind of migration path.
16:10:36 <nirik> ha ha ha ha. ;) no.
16:10:41 <sgallagh> ...
16:10:59 <adamw> it really ought not to be too hard for it to read the yum-cron config and obsolete yum-cron.
16:11:11 <adamw> this is the kind of thing we ought to be doing if we claim to care. sigh.
16:11:14 <simo> I have to go
16:11:17 <simo> thanks for the meeting
16:11:19 <adamw> anyhow, yeah, we're kinda rambling
16:11:19 <simo> it was good
16:11:21 <simo> byez
16:12:55 <sgallagh> OK, I'm closing out the meeting. Thanks for coming, folks.
16:13:00 <sgallagh> #endmeeting