[16:00] <pitti> hello
[16:00] <mdeslaur> \o
[16:03] <mdeslaur> hrm
[16:04]  * slangasek waves
[16:05] <infinity> \o/
[16:06] <slangasek> http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-03-31-16.02.html says kees is chair?
[16:06] <slangasek> else mdeslaur
[16:07]  * stgraber waves
[16:08] <slangasek> kees: are you chairing? :)
[16:08]  * mdeslaur waits a minute for kees
[16:09] <mdeslaur> ok, looks like kees is a no-show again
[16:09] <mdeslaur> #startmeeting
[16:09] <meetingology> Meeting started Tue Apr 14 16:09:24 2015 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:09] <meetingology> Available commands: action commands idea info link nick
[16:09] <mdeslaur> [topic] Apologies
[16:09] <mdeslaur> nobody
[16:09] <mdeslaur> [topic] Action review
[16:09] <mdeslaur> nothing
[16:10] <mdeslaur> [topic] Mailing list archive
[16:10] <mdeslaur> so it looks like we've responded on-list to MAAS
[16:10] <mdeslaur> whoops
[16:10] <mdeslaur> to docker
[16:10] <mdeslaur> does anyone have anything else they'd like to say about the new docker proposal?
[16:10] <pitti> +1 on that, LGTM now
[16:11] <pitti> the previous per-series packaging was scary, but that's gone now
[16:11] <mdeslaur> yeah, +1 from me as well.
[16:12] <pitti> caribou: *prod*
[16:12] <caribou> yes, just want to have TB's opinion on an MRE for sosreport
[16:13] <caribou> it is a fast moving project with many new inclusions
[16:13] <caribou> and not possible to adhere to SRU rules when adding new plugins
[16:13] <infinity> caribou: That description is exactly the opposite of what MREs are (usuaully) for.
[16:13] <pitti> what does that do, roughly?
[16:13] <caribou> so I think that it would be beneficial to have the current upstream version on Ubuntu for all stable rel
[16:14] <caribou> collect configuration & logs on running systems for offline analtysis
[16:14] <pitti> i. e. a program which shows and manually sends data, or automatic in the background, etc?
[16:14] <mdeslaur> it seems to be pretty self-contained and nothing seems to depend on it, so at least there's that
[16:15] <caribou> for instance, a new plugin was added for cloud-init which will not be available to any of the stable release
[16:15] <caribou> since it is not part of any stable release and will only make it to "W"
[16:15] <pitti> it sends it to a location you configure, or to canoincal?
[16:15] <caribou> so the possibility to have the same 'recent' version on stable release would be a bonus
[16:15] <slangasek> manual
[16:15] <pitti> i. e. with SRUs is there a chance that we'd suddenly leak private data which it didn't before on that release?
[16:15] <caribou> infinity: I was told  that MRE would be a solution for that
[16:15] <slangasek> it's not really an MRE
[16:15] <caribou> pitti: manual
[16:15] <slangasek> but that's a nomenclature question
[16:16] <pitti> TBH I think I need some more details of what that does, how new versions impact stable releases, etc.
[16:16] <slangasek> conceptually, as a tool that's used by support to gather information from a customer's system, I think it makes sense to allow it to be updated
[16:17] <slangasek> because the extent of the interface from the user is "run this command, get results back from the Canonical support team"
[16:17] <caribou> pitti: there is confidential data scrubbing built in, but there is always a chance of bugs around this
[16:17] <pitti> caribou: if that's manual configurations, how do me make sure that newer upstream releases work with older configs, and don't suddenly drop config options/information that's sent, or change their format?
[16:17] <slangasek> so it seems analogous to me to other exceptions we've made for software where the server interface has changed
[16:17] <slangasek> just that in this case the "server interface" is the support team
[16:18] <caribou> pitti: but this would affect the dev release in the same way
[16:18] <pitti> ah, so it does send data to Caonical, not to the admin's servers
[16:18] <caribou> pitti: the tool doesn't send anything
[16:19] <caribou> pitti: it produces a tarball to be uploaded "somewhere" by the user
[16:19] <pitti> ah, ok
[16:19] <caribou> pitti: the only output is a tarball in /tmlp
[16:19] <caribou> s/tmlp/tmp
[16:19] <infinity> I'm not against it conceptually.
[16:19] <pitti> so it's intended for e. g. the Canoincal support team, so it's ok if the format/content changes?
[16:19] <infinity> As Martin says, though, are there config files, is migration guaranteed to be sane, etc?
[16:20] <pitti> yeah, I'm mostly interested in what this does structurally, and what's the worst thing that can happen
[16:20] <pitti> .. if a new upstream version changes format or drops files, etc.
[16:20] <caribou> pitti: worst thing is that some collection would be missing (which is the case in the current situation)
[16:20] <mdeslaur> perhaps we could better decide if you sent an email to the list with a description of what the tool does, who uses it, what config is uses, what it produces, and the types of changes that have happened in the past?
[16:20] <caribou> pitti: this is the current situation with SRU
[16:21] <caribou> mdeslaur: that was my intent, but I wanted a first feeling for it
[16:21] <caribou> mdeslaur: no point in formally proposing it if the first reaction is totally negative
[16:21] <pitti> I'm generally not opposed to SRU exceptions as long as they are done in a safe and sane way
[16:22] <mdeslaur> I'm open to the idea, I think this type of tool is something that is definitely worth considering for an exception
[16:22] <caribou> pitti: I think that regression issues would be restricted to the output content
[16:22] <pitti> ^ agreed; I woudl just like to understand what exactly it is and what the impact is :)
[16:22] <pitti> caribou: right, understood
[16:22] <caribou> mdeslaur: pitti: Fine, I will send an email with all the details requested
[16:23] <pitti> caribou: so I'm trying to find out whether that would break automatic evaluation of the content
[16:23] <mdeslaur> caribou: ok, I think we're all open to the idea, and we'll await your post
[16:23] <caribou> thanks to the TB, this will help in writing the email
[16:23] <caribou> this is all I had
[16:23] <pitti> caribou: thanks
[16:23] <mdeslaur> thanks caribou
[16:24] <mdeslaur> doesn't look like there was anything else to discuss on the list
[16:24] <mdeslaur> [topic] Community bugs
[16:24] <mdeslaur> None
[16:24] <mdeslaur> [topic] Next chair
[16:25] <mdeslaur> looks like it's pitti?
[16:25] <infinity> or kees. :P
[16:25] <pitti> ack
[16:25] <slangasek> ;)
[16:25] <mdeslaur> ok, so kees if he's still alive, then pitti
[16:25] <infinity> Yes, that.
[16:25] <mdeslaur> Does anyone have anything else they would like to discuss?
[16:26] <pitti> nothing from me
[16:26] <slangasek> not I
[16:26] <mdeslaur> ok, that's it for today folks
[16:26] <mdeslaur> #endmeeting
[16:26] <meetingology> Meeting ended Tue Apr 14 16:26:43 2015 UTC.
[16:26] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-04-14-16.09.moin.txt
[16:26] <stgraber> thanks!
[16:26] <mdeslaur> thanks!
[16:26] <caribou> thanks!
[16:27] <pitti> cheers
[16:27] <slangasek> thanks!