[00:00] uds-gb-f: This session has ended. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Other | Future Release Infrastructure | Url: http://summit.ubuntu.com/uds-q/meeting/20605/other-q-future-release-infrastructure/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [00:13] Are different flavours able to queue up builds themselves or is there a bottleneck on a subset of people with necessary permissions to do that? [00:14] Does introducing new images still require modifying the actual image build infrastructure code? Or is that stuff abstracted entirely into config files? [00:17] Why is that necessary to accomplish that 5 minute target? PES could probably do that currently based on your current number of ISOs. [00:18] (with ARM being the exception) [00:18] RAM doesn't provide that much gain over large disk cache [00:23] PES has info about hardware and the diminishing returns. [00:23] Hello?? :( [00:28] +1 to smagoun. [00:29] If we do use launchpad-buildd, I strongly suggest we use some sort of API instead of tightly coupling [00:29] so that for example Offspring could sub in different 'farm provider' such as launchpad-buildd [00:29] and more importantly that launchpad-buildd doesn't become a hard dependency of Ubuntu's image build infrastructure [00:30] good question! [00:31] Note that using those buildds use resource that are shared currently with PES [00:32] We can't use the launchpad-buildd farm for image building because there is no interface for us to do that. [00:32] * cody-somerville wonders if people are reading this. :P [00:33] cody-somerville: we are [00:33] at least half the fishbowl just was [00:34] +1 on that [00:34] ugh. sound is breaking up :( [00:35] haha [00:36] so... why not just use cloud again? [00:37] Yes. Why not just use openstack? [00:37] ju ju could setup a guest easily as needed [00:38] Because the load of package building and the load of image building complement each other perfectly, and therefore it makes economic sense to use the same farm for both; which is already effectively a private cloud attached to LP. [00:38] There'd be nothing wrong with extending the LP build farm with cloud instances, but we want it attached to LP. [00:38] Do they really complement? I'm not so sure about that since PES uses that hardware too on a different schedule. [00:39] For Ubuntu, yes, absolutely. [00:39] Very well. [00:40] lp-buildd is generally pretty busy. IT has problems doing what it already does. Why are we investing in it to do another task? It sames very odd to me when we're pushing things like ju ju and openstack. [00:40] We already have hardware running ANOTHER cloud that is more versatile to do what we want. [00:40] you're going to run into the limitations of lp-buildd [00:41] and then it's going to require additional investment [00:41] The nature of the set of machines attached to the farm is orthogonal to the code running on them (launchpad-buildd). [00:41] and there is huge overhead to doing lp development [00:41] UE already does most of the lp-buildd maintenance withouot huge overhead. [00:41] It's split out of LP these days (you may not have realised that). [00:42] It isn't a cloud. It is not elastic. You have one to one per machine. It is a service. Just using virtualization doesn't make it a cloud IMHO. [00:42] it's 'cloud-like'. [00:42] cjwatson, Ok. Neat. Maybe PES should look at using it then if it's split out [00:42] But you could easily make the "machines" attached to it be cloud instances. [00:43] That's not true [00:43] re: slower [00:43] not true. not true. [00:44] (Note that launchpad-buildd is the name of the client, not the buildmaster.) [00:44] cjwatson, do you guys intend to use buildmaster? [00:44] Ask Adam [00:44] He isn't here in this channel [00:44] stgraber, that isn't true [00:45] paral builds [00:45] we have hard data [00:45] packages work load is different story (since packages have more variable workload) [00:46] FWIW it is not true that lp-buildd (in the distro pool) has problems doing what it already does); we're well within capacity right now, and adding livefs builders doesn't look likely to introduce a problem; rather the contrary. [00:46] The PPA pool may be a different story, but we don't care about that for this purpose. [00:47] Adam: Do you guys intend to use builddmaster? [00:47] I'm more opposed to builddmaster than the lp-buildd bit [00:48] did they fix the bottleneck with uploading the results? [00:48] I've never even noticed it [00:48] it was synchronous [00:48] you'll def start noticing it when uploading a bunch of 700mb+ image instead of just packages [00:50] so I can believe that getting lp-buildd to do livefs builds is pretty easy but whats the estimate for the rest of changes needed in LP? [00:50] and is the LP team willing to accept it? [00:50] (with their no LOC increase policy) [00:51] There's lots of LOC easily removable from LP [00:51] (offsetting) [00:53] I'm happy to direct Adam at possibilities :-) [00:53] (I'm on about -900 LOC personally since the new policy) [00:54] uds-gb-f: 5 minutes left in this session! [00:55] (also, re: offspring, there is more to it than just ui and build dispatch. There is also an abstraction around the build tool and common behaviour. the dispatch stuff is probably the least interesting bit so I'm certainly open to seeing we can use lp-buildd and builddmaster OR look at exploring possibilities of more ju-ju/openstack solution that UE might look to migrate to later ) [00:55] uds-gb-f: 4 minutes left in this session! [00:56] uds-gb-f: 3 minutes left in this session! [00:56] Not sure if someone already answered this but question from start: Does introducing new images still require modifying the actual image build infrastructure code? Or is that stuff abstracted entirely into config files? [00:57] uds-gb-f: 2 minutes left in this session! [00:57] The former, I'm afraid. I was just having a conversation with smagoun about that; it's been a more sensible decision for us than it would have been for you (given that we add new image types maybe once a year, vs. once every two and a half minutes) [00:58] It's in the category of "would be nice to improve, but not really a priority" [00:58] uds-gb-f: 1 minute left in this session! [00:59] uds-gb-f: This session has ended. [00:59] cjwatson, Ack. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Currently no events are active in this room - http://summit.ubuntu.com/uds-q/grand-ballroom-f/ - http://ubottu.com/uds-logs/%23ubuntu-uds-grand-ballroom-f.log === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: QA | Canonical QA CoP meetup at UDS | Url: http://summit.ubuntu.com/uds-q/meeting/20469/qa-q-community-of-practice/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [16:01] hi all! [16:07] https://wiki.canonical.com/CoP/QA [16:17] hello? [16:17] hi [16:17] https://wiki.ubuntu.com/QATeam/AutomatedTesting/UbuntuAutomationTestHarness [16:18] https://launchpad.net/ubuntu-automation-test-harness [16:18] Maybe you said this earlier, but are you making use of juju and maas where appropriate? [16:19] Xpresser wiki page: https://wiki.ubuntu.com/Xpresser [16:19] hrmph too late [16:20] mmm, the wiki needs some update... [16:21] hi gema [16:21] hey gema [16:21] hey! [16:21] dpb_: we will be using juju and maas where appropriate, we are actually starting to use maas on our lab next week [16:22] gema: cool! I'll check it out when you get further. [16:22] dpb_: but we will also take into account that the tests may need to be run on low end hardware by some users, so we won't be prescriptive about the provisioning method [16:23] ok, that sneeze scared me [16:34] http://ubuntuone.com/3NcUIy76r5Et5jmYkhYwA3 [16:34] http://ubuntuone.com/3OK0Dkmy9iOwm8WRgQMRz8 [16:34] ^^ video of xpresser at work (awesome) [16:49] uds-gb-f: 5 minutes left in this session! [16:50] uds-gb-f: 4 minutes left in this session! [16:51] uds-gb-f: 3 minutes left in this session! [16:52] uds-gb-f: 2 minutes left in this session! [16:53] uds-gb-f: 1 minute left in this session! [16:54] uds-gb-f: This session has ended. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Community | IRC team meeting and IRCC review | Url: http://summit.ubuntu.com/uds-q/meeting/20706/community-q-ircc/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [16:59] yes [17:04] morning all [17:04] o/ [17:04] :D [17:06] bah stream is breaking up :/ [17:06] It might clear up [17:06] fine here [17:07] no problem here. [17:07] vlc [17:07] parole [17:07] lets see anywya [17:07] you are doing great! [17:08] I love it. ;) [17:08] (stream has cleared up btw) [17:12] What plans do we have for the better integration of LP/access lists? [17:13] https://docs.google.com/spreadsheet/ccc?key=0Ankl5FhsdSiZdGZVV2ZuLVRwa2c5M3pqX3BEaUhXMFE [17:14] Have you talked to tsimpson about it yet? (we used to have a nice script for part of the process) [17:15] There are legacy ircc people with founder access on some lists, you may also want to have a look at founders in the core chans. [17:16] Thats another story altogether as he is the GC for those as well ;) [17:18] council's which are responsible for certain areas should have founder access in those channels (ie. Kubuntu Council) [17:18] your English is slipping [17:18] * Myrtti slaps jussi with an UGG boot [17:18] :/ [17:19] AlanBell: carry on. [17:21] yay, I've made myself unavailable for selection for IRCC \o/ [17:21] https://wiki.ubuntu.com/IRC/IrcCouncil [17:21] We need to be prodding those we think would make good people [17:21] (re ircc applicants) [17:21] there will be several applications, it's totally different thing will any of them be good. [17:23] I agree with that, I had the same policy when I was in the ircc [17:23] good thing that IRCC will review before sending short list to CC [17:24] ircc sends full list to cc [17:24] oh dear. [17:24] oh good. [17:25] cant we just steal pleia2 as the last ircc member? :P :D [17:25] :P [17:26] i second that [17:26] kick her off the CC!! :D [17:26] haha [17:27] I had some discussion earlier about pulling people into places temporarily as observers, to lessen the "intrigue" of things like ops and ircc. has there been any thought on that? [17:28] I am talking about throughout the cycle, for set periods of time [17:29] ie. a 2 week "observation" [17:29] into what places? [17:29] into the ircc private channel that we don't really [17:29] -ops -ircc depending on the person's current role [17:29] use much [17:29] (why don't we just open up -ops again once and for all) [17:30] the main argument against removing the "no idling" policy in -ops is that we don't want to turn it into a spectator sport [17:30] allow people to come in, without disturbing of course [17:31] me also at the moment [17:31] I need brainbleach, I was about to suggest a technical solution to a social problem [17:31] i hate having to tell people "now you must leave, go away, bye" though :P unless they are trolls at least [17:32] there's not a whole lot of point in having -ops open, as it is logged. the most someone will get is not to have to wait an hour for the logs to update [17:32] why not just +m? [17:32] Faqtotum: see above :) [17:33] also, that would make it difficult for people to join and get an issue solved [17:33] AlanBell: often people come to -ops to inform us of things [17:33] AlanBell: then they're told to leave [17:33] loco team operators don't idle in -ops, they usually idle in -irc or -ops-team [17:33] AlanBell: after a while, it gets a bit embarrassing for both parties [17:33] Faqtotum: you have just suggested a technical solution to a social problem, which would probably cause more problems than it would solve [17:33] -ops is for the core channels [17:34] i mean, there's a lot to be said for having everything open for all to see [17:34] I think leaving the current policy in place and enforcing it when there are issues rather than by default would work fine. "We reserve the right to remove idlers", rather than "no idling gtfo" [17:34] (by the way my understanding of spoken english is quite bad, so i'm not able to follow everything you say) [17:34] Afterall there is always http://irclogs.ubuntu.com/2012/ [17:34] dax: well sure, we'd of course reserve the right to remove troublemakers, like we do everywhere [17:35] ++ [17:35] AlanBell: dingdingding [17:35] you have won the internets [17:35] AlanBell: yeah, that's true as well [17:35] the problem with making those people ops though is that some people aren't necessarily aware of everything that goes with being an op [17:36] as I mentioned in my email about the subject [17:36] Which is why we have a probation perod [17:36] and some people don't want to be, and some aren't suitable ops, and some would be driven insane by it... [17:36] some people also just don't want to be ops, just help us out by pointing things out (without calling ! ops) [17:36] yeeeesss... but some people don't know about the amount of stress involved [17:36] tsimpson: exactly [17:37] tsimpson: well, it's also true that nobody is *forced* to ban anyone, i think you can be appointed as an op and acts as *you* feel is best, for yourself too... [17:38] LjL: I just wouldn't want to make people feel like they either become an op, or don't join -ops to communicate something [17:38] tsimpson: me neither! that's why i'd like an open -ops, to encourage that more :P [17:39] LjL: I also don't want mediation to become a spectator sport, or have some odd +mz and +v combination that will just be hell to maintain :) [17:39] exactly what we need, more channels and bureacracy to deal with. [17:40] uds-gb-f: 5 minutes left in this session! [17:40] we don't like automatic +o [17:40] tsimpson: i'd just solve that by being firm about the fact that the ones with +v (the ops) are the ones supposed to mediate, and the others shouldn't intervene. remember -ops *used* to be open and we didn't really have huge trouble with that... i think we closed it mainly because we were afraid (maybe rightly, at the time) of actual attackers. but now we also have -ops-team for more private info [17:40] the general freenode guideline is only use +o when you _need_ to [17:40] otherwise it raises the "heat" of a channel [17:41] uds-gb-f: 4 minutes left in this session! [17:41] LjL: I remember those days too, that's how I got involved ;) so I agree with the principal [17:42] uds-gb-f: 3 minutes left in this session! [17:42] cant you just embed the irc in the same page as the etherpad? [17:43] uds-gb-f: 2 minutes left in this session! [17:43] Can't that be solved by better documentation/upkeep on the summit pages afterwards? [17:43] udsbotu: stop with the pressure! [17:43] LjL: I am only a bot, please don't think I'm intelligent :) [17:43] I miss Mr. T [17:43] http://mumble.libertus.co.uk:9001/p/udspad [17:43] Im glad you cant hear Elodi screaming :D [17:44] uds-gb-f: 1 minute left in this session! [17:45] uds-gb-f: This session has ended. [17:45] (mobile) accessibility needs to be assessed === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Currently no events are active in this room - http://summit.ubuntu.com/uds-q/grand-ballroom-f/ - http://ubottu.com/uds-logs/%23ubuntu-uds-grand-ballroom-f.log [17:46] I tend to leave my laptop when attending conferences and use my mobile instead [17:46] and accessibility needs to be assessed anyway [17:46] looks like we've already solved the "I have to go find logs and do math on times" problem (see above, second link) [17:46] i am on my phone here, electing not to bring a laptop on public transit [17:47] as such, i'm in the irc sessions and not etherpad [17:48] having irc and etherpad open on a phone at the same time is just not practical [17:49] "webirc" [17:49] :) [17:49] thanks [17:49] cya [17:49] I just hope for irc integration [17:50] Thank you guys/gals. :) [17:50] yw === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Cloud & Server | Ubuntu Cloud Archive | Url: http://summit.ubuntu.com/uds-q/meeting/20356/servercloud-q-cloud-archive/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [18:49] uds-gb-f: 5 minutes left in this session! [18:50] uds-gb-f: 4 minutes left in this session! [18:51] uds-gb-f: 3 minutes left in this session! [18:52] uds-gb-f: 2 minutes left in this session! [18:53] uds-gb-f: 1 minute left in this session! [18:54] uds-gb-f: This session has ended. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Community | Ubuntu LoCo Council Items for the Quantal cycle | Url: http://summit.ubuntu.com/uds-q/meeting/20787/community-q-lococouncil/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [19:55] uds-gb-f: 5 minutes left in this session! [19:56] uds-gb-f: 4 minutes left in this session! [19:57] uds-gb-f: 2 minutes left in this session! [19:58] uds-gb-f: 1 minute left in this session! [19:59] uds-gb-f: This session has ended. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Currently no events are active in this room - http://summit.ubuntu.com/uds-q/grand-ballroom-f/ - http://ubottu.com/uds-logs/%23ubuntu-uds-grand-ballroom-f.log === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Cloud & Server | XCP Toolstack Improvements | Url: http://summit.ubuntu.com/uds-q/meeting/20367/servercloud-q-xcp/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [22:08] about to start... [22:55] uds-gb-f: 5 minutes left in this session! [22:56] uds-gb-f: 4 minutes left in this session! [22:57] uds-gb-f: 3 minutes left in this session! [22:58] uds-gb-f: 2 minutes left in this session! [22:59] uds-gb-f: 1 minute left in this session! [23:00] uds-gb-f: This session has ended. === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Currently no events are active in this room - http://summit.ubuntu.com/uds-q/grand-ballroom-f/ - http://ubottu.com/uds-logs/%23ubuntu-uds-grand-ballroom-f.log === fenris_ is now known as Guest98532 === Guest98532 is now known as ejat === ChanServ changed the topic of #ubuntu-uds-grand-ballroom-f to: Track: Foundations | Continuous scan of the archive for ISA (in)compatibility | Url: http://summit.ubuntu.com/uds-q/meeting/20490/foundations-q-isa-scanning/ | Audio: http://icecast.ubuntu.com:8000/grand-ballroom-f.ogg.m3u [23:54] uds-gb-f: 5 minutes left in this session! [23:55] uds-gb-f: 4 minutes left in this session! [23:56] uds-gb-f: 3 minutes left in this session! [23:57] uds-gb-f: 2 minutes left in this session! [23:58] uds-gb-f: 1 minute left in this session! [23:59] uds-gb-f: This session has ended.