| === markthomas|away is now known as markthomas | ||
| === markthomas is now known as markthomas|away | ||
| === kees_ is now known as kees | ||
| pitti | hello | 16:00 |
|---|---|---|
| mdeslaur | \o | 16:00 |
| mdeslaur | hrm | 16:03 |
| * slangasek waves | 16:04 | |
| infinity | \o/ | 16:05 |
| === markthomas|away is now known as markthomas | ||
| 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:06 |
| * stgraber waves | 16:07 | |
| slangasek | kees: are you chairing? :) | 16:08 |
| * mdeslaur waits a minute for kees | 16:08 | |
| 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:09 |
| 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:10 |
| pitti | the previous per-series packaging was scary, but that's gone now | 16:11 |
| mdeslaur | yeah, +1 from me as well. | 16:11 |
| pitti | caribou: *prod* | 16:12 |
| caribou | yes, just want to have TB's opinion on an MRE for sosreport | 16:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| pitti | cheers | 16:27 |
| slangasek | thanks! | 16:27 |
| === 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!