| === markthomas|away is now known as markthomas | ||
| === markthomas is now known as markthomas|away | ||
| * slangasek waves | 15:59 | |
| mdeslaur | hi! | 16:00 |
|---|---|---|
| pitti | \o | 16:00 |
| === markthomas|away is now known as markthomas | ||
| slangasek | #startmeeting | 16:01 |
| meetingology | 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 |
| meetingology | Available commands: action commands idea info link nick | 16:01 |
| slangasek | [TOPIC] Apologies | 16:01 |
| slangasek | no apologies sent on the list | 16:01 |
| slangasek | kees, infinity appear to be absent | 16:01 |
| slangasek | but we nevertheless have a quorum, so carrying on :) | 16:02 |
| slangasek | [TOPIC] Action review | 16:02 |
| slangasek | ACTION: slangasek to forward complaint to Canonical legal | 16:02 |
| slangasek | carried over, again | 16:02 |
| slangasek | 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:02 |
| pitti | FTR, stgraber is on holidays? | 16:03 |
| stgraber | no I'm not :) | 16:03 |
| mdeslaur | he just wishes :) | 16:04 |
| stgraber | :) | 16:04 |
| slangasek | nope, we're all still working, no matter how much our brains are overheating in this weather ;) | 16:04 |
| slangasek | [TOPIC] Mailing list archive | 16:05 |
| slangasek | there was a mail from apw this morning, which I just saw in the queue and approved through | 16:05 |
| slangasek | I'm guessing most people haven't read it yet | 16:05 |
| pitti | ah, I already wondered | 16:05 |
| slangasek | Subject: Ubuntu Fan Updates for Trusty and Vivid | 16:05 |
| pitti | I quickly read through it, but I'm not entirely sure about the impact yet | 16:05 |
| mdeslaur | I skimmed it, but I'd have to look at the patch to form an opinion | 16:06 |
| slangasek | for those who don't know, Ubuntu Fan is a clever stateless network multiplexer | 16:06 |
| slangasek | it's a useful feature to have on cloud instances running containers | 16:06 |
| slangasek | apw had approached me and asked me if it was SRUable | 16:06 |
| pitti | it sounds similar to IPv4LL and NAT, and all the other crazy things people do to avoid IPv6 :) | 16:06 |
| slangasek | and I expressed concern that this doesn't really fit our existing SRU policy, so should be discussed at a higher level | 16:07 |
| pitti | but AFAIUI this is mostly a new feature, ignoring some undocumented preview that was already in the trusty kernel | 16:07 |
| slangasek | vivid kernel | 16:07 |
| pitti | i. e. the regression potential is that someone made use of that in trusty, and it's going to change/break? | 16:07 |
| pitti | ah | 16:07 |
| pitti | so for trusty this is entirely new | 16:07 |
| slangasek | yes, the risk of regression potential is fairly low because it's a new feature | 16:07 |
| stgraber | my main concern is the changes to iproute2 and other core bits to support the feature | 16:08 |
| mdeslaur | is this upstream yet? what are the odds that it gets changed in an incompatible way while going upstream? | 16:08 |
| slangasek | 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 |
| pitti | 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 |
| slangasek | we've moved the line a few times wrt hardware enablement, to accomodate cloud substrate requirements | 16:08 |
| stgraber | 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 |
| slangasek | 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 |
| pitti | (wrt. security/quality review, and general sanity) | 16:09 |
| pitti | so while from a regresssion potential POV this seems manageable (assuming that iproute2 only gets new features, and no changed behaviour) | 16:10 |
| stgraber | 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 |
| pitti | 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:10 |
| slangasek | so, I'd appreciate it if we could separate our SRU team hats from our TB hats here, difficult as that is :) | 16:11 |
| pitti | sure; this is all TB anyway, as it's clearly outside of SRU policy | 16:11 |
| slangasek | 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 |
| slangasek | but to discuss whether the SRU policy should, or should not, allow for updates such as this | 16:12 |
| stgraber | ah, simple answer then, it shouldn't | 16:12 |
| pitti | personally I would never like to give out a blanket permit for things like this | 16:12 |
| slangasek | pitti: well, I have the opposite response: that we shouldn't give /exceptions/ for things like this :) | 16:13 |
| pitti | even with this concrete case I have some serious concerns, I don't see how to allow even more general cases | 16:13 |
| stgraber | 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:13 |
| pitti | 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 |
| slangasek | 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:14 |
| slangasek | so I'd say that taking the pulse here suggests that we don't want this SRU | 16:16 |
| pitti | hm, so we could imagine how the fan proposal would have to look like in order for us to consider it acceptable | 16:16 |
| stgraber | 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 |
| pitti | and then generalize that? | 16:16 |
| slangasek | shall we follow up on the mailing list? | 16:16 |
| slangasek | stgraber: uh? I'm in no way talking about codifying "the TB can overrule" | 16:16 |
| mdeslaur | 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:17 |
| slangasek | speaking only for myself as an SRU team member: no | 16:18 |
| pitti | with my former SRU hat on: I wouldn't be | 16:18 |
| slangasek | because having the power to rule on it means we'll be constantly asked to rule on it | 16:18 |
| stgraber | 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:18 |
| pitti | processing SRUs is enough work without having to argue about new features all the time | 16:19 |
| pitti | I'd actually be okay with new features in LTSes under reasonable circumstances; we do it all the time already, after all | 16:19 |
| pitti | (new landscape or maas versions, etc.) | 16:19 |
| slangasek | 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:19 |
| pitti | but they should have a reasonably low potential for introducing new bugs and security holes, which this particular proposal totally fails at | 16:20 |
| pitti | right -- e. g. for the HW enablement we have a generic justification in the policy | 16:20 |
| pitti | so if/once we agree to this particular proposal, we could then generalize it and see on which grounds we accept it | 16:21 |
| slangasek | 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:22 |
| stgraber | yeah, the kernel side isn't a big concern of mine because we don't force those on our existing users | 16:23 |
| slangasek | I also think the SRU process is adequate for dealing with the risks of regression, and doesn't need direct TB involvement | 16:23 |
| stgraber | iproute2 however is a bit more problematic | 16:23 |
| slangasek | 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 |
| pitti | well, we wouldn't push/force it into trusty unless we were planning to actually use that feature, no? | 16:24 |
| pitti | i. e. in some cloud workload via iproute2? | 16:24 |
| stgraber | 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 |
| pitti | right, the normal kernel backporting process kind of gets us that through the backdoor, but it would be inert without userspace changes | 16:25 |
| pitti | so it's much less adding the new kernel feature, but rather making use of that by our default tools | 16:25 |
| stgraber | right, you need the ubuntu-fan package and tools to talk to iproute2 to talk to the new kernel netlink interface | 16:25 |
| slangasek | 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 |
| pitti | 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 |
| pitti | slangasek: it's not? that's not at all clear to me | 16:26 |
| stgraber | 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 |
| stgraber | because if iproute2 breaks somehow, that means no network on the affected machine and that's kinda bad | 16:27 |
| mdeslaur | part of the issue here is this seems to be an ubuntu-specific feature | 16:27 |
| pitti | slangasek: it's very easy to accidentally or deliberately enable it on upgrades | 16:27 |
| slangasek | pitti: it certainly is not, it's a completely new bridge type | 16:27 |
| mdeslaur | it's not as if it's a backport of something present in a new version | 16:27 |
| slangasek | 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 |
| pitti | right, "ubuntu specific" doesn't belong into SRU policy, that should be general development policy | 16:29 |
| pitti | (FWIW, I really don't like having this in vivid either) | 16:29 |
| mdeslaur | 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:30 |
| pitti | 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 |
| pitti | the "change userspace to make use of it" is what I'd like to understand more, as right now it sounds awfully dangerous | 16:31 |
| pitti | 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:32 |
| pitti | all of which is really unrelated to SRUing this to trusty, but should retroactively be done for vivid too | 16:33 |
| slangasek | all of that still doesn't pass the SRU policy as it stands, and only supports making an exception? | 16:34 |
| slangasek | I'm against making an exception | 16:35 |
| pitti | 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 |
| pitti | it shoudl still be ack'ed individually IMHO, but it would be a guideline what the TB would look at | 16:35 |
| pitti | (TBH I have a bigger problem with the feature itself than with backporting it) | 16:36 |
| slangasek | ok; so you think that at least potentially this is something that we would want codified in the SRU policy as allowable | 16:38 |
| pitti | yes, I do | 16:38 |
| mdeslaur | pitti: acked by who, the SRU team or the tech board? | 16:38 |
| pitti | 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 | pitti | and then generalize that? | 16:38 |
| slangasek | I agree, though I'm not yet sure what shape it should take | 16:38 |
| pitti | mdeslaur: my feeling is "TB" at least initially | 16:39 |
| mdeslaur | ok | 16:39 |
| slangasek | 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 |
| pitti | this shouldn't be a "toss over the fence" kind of thing, but similar to preliminary MREs | 16:39 |
| pitti | 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 |
| slangasek | not just MREs :) | 16:40 |
| pitti | 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:40 |
| slangasek | [ACTION] slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases | 16:41 |
| meetingology | ACTION: slangasek to document maas, juju, docker exceptions on https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases | 16:41 |
| pitti | slangasek: juju is on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 16:41 |
| slangasek | pitti: yes, but it's not actually an MRE so I'm going to move it :) | 16:42 |
| pitti | maas was proposed, but never got signed off because the interview wasn't finished | 16:42 |
| pitti | slangasek: ack | 16:42 |
| pitti | slangasek: I'm happy to look at our existing MacroReleaseExceptions and come up with a proposal for a policy amendment for next time | 16:42 |
| slangasek | so - next steps? should we evolve this on the mailing list? | 16:43 |
| pitti | as I usually responded to the bulk of MRE requests on the ML anyway | 16:43 |
| pitti | I think there's two steps: | 16:43 |
| pitti | 1) amend the policy for new features in LTS (as that's clearly a direction we've gone in in the past years) | 16:43 |
| pitti | 2) respond to that concrete case with our gripes and request for more information about them | 16:44 |
| slangasek | pitti: do you want to drive #1? | 16:44 |
| pitti | slangasek: yes | 16:44 |
| mdeslaur | pitti: that sounds reasonable | 16:44 |
| slangasek | [ACTION] pitti to propose amendment to general SRU policy for new features in LTS | 16:44 |
| meetingology | ACTION: pitti to propose amendment to general SRU policy for new features in LTS | 16:44 |
| slangasek | [ACTION] all to respond to the Ubuntu Fan SRU proposal on list | 16:45 |
| meetingology | ACTION: all to respond to the Ubuntu Fan SRU proposal on list | 16:45 |
| slangasek | [TOPIC] community bugs | 16:46 |
| slangasek | https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard | 16:46 |
| slangasek | empty | 16:46 |
| slangasek | [TOPIC] Select a chair for the next meeting | 16:46 |
| slangasek | I believe that's stgraber, with infinity as backup, yes? | 16:46 |
| stgraber | yep | 16:47 |
| slangasek | [INFO] Next meeting 2015-07-21, 17:00 London time. Chair: stgraber (next: infinity) | 16:47 |
| slangasek | anything else that I've missed? | 16:48 |
| pitti | nice to have a "real" meeting for a change :) | 16:49 |
| mdeslaur | hehe, yes :) | 16:49 |
| pitti | nothing else from me | 16:49 |
| slangasek | :) | 16:49 |
| slangasek | #endmeeting | 16:49 |
| meetingology | Meeting ended Tue Jul 7 16:49:58 2015 UTC. | 16:49 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-07-07-16.01.moin.txt | 16:49 |
| slangasek | thanks, all! | 16:50 |
| mdeslaur | thanks slangasek, thanks all | 16:50 |
| pitti | thanks everyone | 16:50 |
| stgraber | thanks | 16:50 |
| pitti | et bonne nuit ! | 16:50 |
| stgraber | :) | 16:51 |
| === markthomas is now known as markthomas|away | ||
| === markthomas|away is now known as markthomas | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!