== Meeting information == * #ubuntu-meeting-2 Meeting, 07 Jul at 16:01 — 16:49 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-07-07-16.01.log.html]] == Meeting summary == === Apologies === The discussion about "Apologies" started at 16:01. === Action review === The discussion about "Action review" started at 16:02. === Mailing list archive === The discussion about "Mailing list archive" started at 16:05. * ''ACTION:'' slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases * ''ACTION:'' pitti to propose amendment to general SRU policy for new features in LTS * ''ACTION:'' all to respond to the Ubuntu Fan SRU proposal on list === community bugs === The discussion about "community bugs" started at 16:46. * ''LINK:'' https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard === Select a chair for the next meeting === The discussion about "Select a chair for the next meeting" started at 16:46. * Next meeting 2015-07-21, 17:00 London time. Chair: stgraber (next: infinity) == Vote results == == Action items, by person == * pitti * pitti to propose amendment to general SRU policy for new features in LTS * slangasek * slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases == Done items == * (none) == People present (lines said) == * slangasek (61) * pitti (59) * stgraber (16) * mdeslaur (11) * meetingology (6) == Full Log == 16:01 #startmeeting 16:01 Meeting started Tue Jul 7 16:01:19 2015 UTC. The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:01 16:01 Available commands: action commands idea info link nick 16:01 [TOPIC] Apologies 16:01 no apologies sent on the list 16:01 kees, infinity appear to be absent 16:02 but we nevertheless have a quorum, so carrying on :) 16:02 [TOPIC] Action review 16:02 * slangasek slangasek to forward complaint to Canonical legal 16:02 carried over, again 16:02 again, if anyone felt strongly about stealing this from me I wouldn't stand in their way, otherwise I'll keep it on my todo 16:03 FTR, stgraber is on holidays? 16:03 no I'm not :) 16:04 he just wishes :) 16:04 :) 16:04 nope, we're all still working, no matter how much our brains are overheating in this weather ;) 16:05 [TOPIC] Mailing list archive 16:05 there was a mail from apw this morning, which I just saw in the queue and approved through 16:05 I'm guessing most people haven't read it yet 16:05 ah, I already wondered 16:05 Subject: Ubuntu Fan Updates for Trusty and Vivid 16:05 I quickly read through it, but I'm not entirely sure about the impact yet 16:06 I skimmed it, but I'd have to look at the patch to form an opinion 16:06 for those who don't know, Ubuntu Fan is a clever stateless network multiplexer 16:06 it's a useful feature to have on cloud instances running containers 16:06 apw had approached me and asked me if it was SRUable 16:06 it sounds similar to IPv4LL and NAT, and all the other crazy things people do to avoid IPv6 :) 16:07 and I expressed concern that this doesn't really fit our existing SRU policy, so should be discussed at a higher level 16:07 but AFAIUI this is mostly a new feature, ignoring some undocumented preview that was already in the trusty kernel 16:07 vivid kernel 16:07 i. e. the regression potential is that someone made use of that in trusty, and it's going to change/break? 16:07 ah 16:07 so for trusty this is entirely new 16:07 yes, the risk of regression potential is fairly low because it's a new feature 16:08 my main concern is the changes to iproute2 and other core bits to support the feature 16:08 is this upstream yet? what are the odds that it gets changed in an incompatible way while going upstream? 16:08 however, the SRU policy has always been rather clear that new features don't belong in SRUs - with the exception of hardware enablement 16:08 yeah, that's my main gripe with it -- there's no indication of whether this has ever been reviewed by kernel developers, or proposed for inclusion 16:08 we've moved the line a few times wrt hardware enablement, to accomodate cloud substrate requirements 16:09 so last I heard, it's not upstream and we're not actively pushing for it to be upstreamed in its current shape, it also uses kernel identifiers for the tunnel type which may potentially be used by another in-kernel tunneling technology at some point, causing a clash 16:09 but I don't think I can justify this under the current SRU policy, so I think there's a higher-level policy discussion to be had rather than just making exceptions 16:09 (wrt. security/quality review, and general sanity) 16:10 so while from a regresssion potential POV this seems manageable (assuming that iproute2 only gets new features, and no changed behaviour) 16:10 so basically from my point of view: 1) ubuntu-fan package itself is fine and safe 2) changes to iproute2 may be risky 3) in-kernel non-upstream tunnel technology when needing unique IDs for netlink is a risk too 16:10 it feels like exposing millions of LTS users with a brand new and largely unreviewed kernel feature that will be exposed to the network is a bit premature 16:11 so, I'd appreciate it if we could separate our SRU team hats from our TB hats here, difficult as that is :) 16:11 sure; this is all TB anyway, as it's clearly outside of SRU policy 16:12 when I asked apw to refer it to the TB, it wasn't because I wanted the TB to analyze the risks of this specific SRU 16:12 but to discuss whether the SRU policy should, or should not, allow for updates such as this 16:12 ah, simple answer then, it shouldn't 16:12 personally I would never like to give out a blanket permit for things like this 16:13 pitti: well, I have the opposite response: that we shouldn't give /exceptions/ for things like this :) 16:13 even with this concrete case I have some serious concerns, I don't see how to allow even more general cases 16:13 backporting of a new major feature into a LTS release is very clearly out of scope for the normal SRU process and as it's not something I want to see abused, I don't believe it makes sense to have the SRU policy allow this 16:14 slangasek: that'ss a good point from the POV that general written-down policy is better than arbitrary exceptions that are handed to whoever shouts the loudest 16:14 if it's justifiable in the specific case (which it may not be), I think that we should address that in the SRU policy. The SRU policy currently says we don't allow new features in, this is a new feature: is the policy wrong, or is the SRU proposal one we should reject 16:16 so I'd say that taking the pulse here suggests that we don't want this SRU 16:16 hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable 16:16 do we really need to update the SRU policy to say that the TB can overule? to me it seems like its stating the obvious... 16:16 and then generalize that? 16:16 shall we follow up on the mailing list? 16:16 stgraber: uh? I'm in no way talking about codifying "the TB can overrule" 16:17 There is a lot of potential for abuse in letting new features in. Is having the power to rule on new features something the SRU team in interested in? 16:18 speaking only for myself as an SRU team member: no 16:18 with my former SRU hat on: I wouldn't be 16:18 because having the power to rule on it means we'll be constantly asked to rule on it 16:18 so my point of view, is keep the SRU policy as is, no new features and have the SRU team reject anything that's a new feature. None of that prevents escalation through the TB for a specific exception as seems to be the case here. 16:19 processing SRUs is enough work without having to argue about new features all the time 16:19 I'd actually be okay with new features in LTSes under reasonable circumstances; we do it all the time already, after all 16:19 (new landscape or maas versions, etc.) 16:19 stgraber: I would not be happy with the TB ever signing off on a specific exception to the new feature rule without being able to articulate a general principle 16:20 but they should have a reasonably low potential for introducing new bugs and security holes, which this particular proposal totally fails at 16:20 right -- e. g. for the HW enablement we have a generic justification in the policy 16:21 so if/once we agree to this particular proposal, we could then generalize it and see on which grounds we accept it 16:22 fwiw my risk analysis of this particular SRU differs from yours - it's already in the vivid kernel, the vivid kernel will land in trusty as part of the hwe process, new kernels have a huge attack surface anyway for security holes and we have a kernel update cadence to deal with that 16:23 yeah, the kernel side isn't a big concern of mine because we don't force those on our existing users 16:23 I also think the SRU process is adequate for dealing with the risks of regression, and doesn't need direct TB involvement 16:23 iproute2 however is a bit more problematic 16:24 anyway, so far I'm hearing a pretty firm "no" - so I think the next steps are to take that back to the mailing list? 16:24 well, we wouldn't push/force it into trusty unless we were planning to actually use that feature, no? 16:24 i. e. in some cloud workload via iproute2? 16:25 well, the feature can be used by anyone, cloud or not, it just shows up as a bridge that you can use with docker, lxc, lxd, ... 16:25 right, the normal kernel backporting process kind of gets us that through the backdoor, but it would be inert without userspace changes 16:25 so it's much less adding the new kernel feature, but rather making use of that by our default tools 16:25 right, you need the ubuntu-fan package and tools to talk to iproute2 to talk to the new kernel netlink interface 16:26 but it's also not as if this is going to be activated on existing systems automatically; someone has to invoke it to make use of it 16:26 in general I don't want to respond to these kinds of requests with a plain "no" (as there's usually a good use case behind it), but more with a "how" 16:26 slangasek: it's not? that's not at all clear to me 16:27 yeah, as I said, I'm not too concerned about the kernel side of it. What I'm concerned with is modifying iproute2 16:27 because if iproute2 breaks somehow, that means no network on the affected machine and that's kinda bad 16:27 part of the issue here is this seems to be an ubuntu-specific feature 16:27 slangasek: it's very easy to accidentally or deliberately enable it on upgrades 16:27 pitti: it certainly is not, it's a completely new bridge type 16:27 it's not as if it's a backport of something present in a new version 16:29 mdeslaur: it's a backport of something present in a new version of the package in Ubuntu. I'm not sure from a policy perspective (as opposed to a risk analysis perspective) that we should distinguish between Ubuntu-specific vs. not 16:29 right, "ubuntu specific" doesn't belong into SRU policy, that should be general development policy 16:29 (FWIW, I really don't like having this in vivid either) 16:30 slangasek: policy no, but it certainly has an impact on the risk. Even more so if there actually are plans to get it upstream and that turns into a compatibility nightmare for users. 16:31 so assuming it *was* a properly reviewed feature in vivid's kernel, I wouldn't have a problem with letting this migrate to trusty as well via the normal backport process 16:31 the "change userspace to make use of it" is what I'd like to understand more, as right now it sounds awfully dangerous 16:32 so the "how to make this palatable" would include an upstream review, plus a more detailled description of the current and planned userspace changes to iproute and other tools, and a regression potential analysis 16:33 all of which is really unrelated to SRUing this to trusty, but should retroactively be done for vivid too 16:34 all of that still doesn't pass the SRU policy as it stands, and only supports making an exception? 16:35 I'm against making an exception 16:35 as for the SRU policy, I think we can make an amendment for backporting features from stable releases to LTSes which have a negligible regression potential 16:35 it shoudl still be ack'ed individually IMHO, but it would be a guideline what the TB would look at 16:36 (TBH I have a bigger problem with the feature itself than with backporting it) 16:38 ok; so you think that at least potentially this is something that we would want codified in the SRU policy as allowable 16:38 yes, I do 16:38 pitti: acked by who, the SRU team or the tech board? 16:38 pitti | hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable 16:38 pitti | and then generalize that? 16:38 I agree, though I'm not yet sure what shape it should take 16:39 mdeslaur: my feeling is "TB" at least initially 16:39 ok 16:39 but I think we're racking up exceptions at this point (maas, juju, proposal for fan) and we should consider whether the current SRU rules are still meeting their purpose 16:39 this shouldn't be a "toss over the fence" kind of thing, but similar to preliminary MREs 16:40 slangasek: right, that's a good point; now that we do have a lot of MREs we have some experience when we allowed them 16:40 not just MREs :) 16:40 and most of the time the "interview" looked fairly similar: automatic/manual test plans and QA procedures, how to ensure that upgrades don't break, regression potential analysis 16:41 [ACTION] slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases 16:41 * meetingology slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases 16:41 slangasek: juju is on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions 16:42 pitti: yes, but it's not actually an MRE so I'm going to move it :) 16:42 maas was proposed, but never got signed off because the interview wasn't finished 16:42 slangasek: ack 16:42 slangasek: I'm happy to look at our existing MacroReleaseExceptions and come up with a proposal for a policy amendment for next time 16:43 so - next steps? should we evolve this on the mailing list? 16:43 as I usually responded to the bulk of MRE requests on the ML anyway 16:43 I think there's two steps: 16:43 1) amend the policy for new features in LTS (as that's clearly a direction we've gone in in the past years) 16:44 2) respond to that concrete case with our gripes and request for more information about them 16:44 pitti: do you want to drive #1? 16:44 slangasek: yes 16:44 pitti: that sounds reasonable 16:44 [ACTION] pitti to propose amendment to general SRU policy for new features in LTS 16:44 * meetingology pitti to propose amendment to general SRU policy for new features in LTS 16:45 [ACTION] all to respond to the Ubuntu Fan SRU proposal on list 16:45 * meetingology all to respond to the Ubuntu Fan SRU proposal on list 16:46 [TOPIC] community bugs 16:46 https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 16:46 empty 16:46 [TOPIC] Select a chair for the next meeting 16:46 I believe that's stgraber, with infinity as backup, yes? 16:47 yep 16:47 [INFO] Next meeting 2015-07-21, 17:00 London time. Chair: stgraber (next: infinity) 16:48 anything else that I've missed? 16:49 nice to have a "real" meeting for a change :) 16:49 hehe, yes :) 16:49 nothing else from me 16:49 :) 16:49 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)