16:01 <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> 
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:02 <slangasek> but we nevertheless have a quorum, so carrying on :)
16:02 <slangasek> [TOPIC] Action review
16:02 * slangasek 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:03 <pitti> FTR, stgraber is on holidays?
16:03 <stgraber> no I'm not :)
16:04 <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:05 <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:06 <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:07 <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:08 <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:09 <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:10 <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:11 <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:12 <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:13 <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:14 <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:16 <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:17 <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:18 <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:19 <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:20 <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:21 <pitti> so if/once we agree to this particular proposal, we could then generalize it and see on which grounds we accept it
16:22 <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:23 <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:24 <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:25 <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:26 <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:27 <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:29 <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:30 <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:31 <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:32 <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:33 <pitti> all of which is really unrelated to SRUing this to trusty, but should retroactively be done for vivid too
16:34 <slangasek> all of that still doesn't pass the SRU policy as it stands, and only supports making an exception?
16:35 <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:36 <pitti> (TBH I have a bigger problem with the feature itself than with backporting it)
16:38 <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:39 <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:40 <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:41 <slangasek> [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 <pitti> slangasek: juju is on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
16:42 <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:43 <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:44 <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 pitti to propose amendment to general SRU policy for new features in LTS
16:45 <slangasek> [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 <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:47 <stgraber> yep
16:47 <slangasek> [INFO] Next meeting 2015-07-21, 17:00 London time.  Chair: stgraber (next: infinity)
16:48 <slangasek> anything else that I've missed?
16:49 <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