=== 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!