[11:54] <TheMuso> Hey amachu.
[11:54] <amachu> TheMuso: Hi
[11:55] <amachu> elky: persia: lifeless:
[11:55] <amachu> Hi all
[11:55] <persia> Good evening.
[11:55] <amachu> and where are zakame and belutz?
[11:55]  * persia loads the agenda
[11:55] <amachu> persia: I just dropped a mail to you :-)
[11:55] <amachu> luckily not as I feared
[11:55] <elky> hi
[11:55] <persia> amachu: Something I need to hunt down before the meeting?
[11:55] <amachu> elky: Hi
[11:56] <amachu> nope, I feared dis-conection and delay due to that
[11:56] <persia> Odd.  Although I'm sure the meeting is now, the wiki page claims it's tomorrow.
[11:56] <amachu> Oh ho!
[11:57] <TheMuso> Sounds like a date mixup.
[11:57] <amachu> TheMuso: yep!
[11:57] <persia> Yeah.  It says "01-October-2008", and it's currently "30-September-2008".
[11:57] <amachu> thats my fault
[11:57] <amachu> mixed up the date
[11:57] <TheMuso> Doesn't matter, we've put 2 and 2 together.
[11:57] <persia> Perhaps we'll have to hunt down the applicants.  I only hope they are prepared.
[11:57] <persia> None are in-channel now :(
[11:58] <amachu> :(
[11:59] <elky> hew is online in -au
[11:59] <elky> but... i have no idea who he is :-/
[11:59] <persia> I've seen Hew in #ubuntu-bugs a fair bit.
[11:59] <TheMuso> He appears to be in #ubuntu-motu also.
[12:00] <persia> OK.  Any ideas for lousyguara or svaksha?
[12:00] <elky> persia, i havent seen svaksha for age
[12:00] <elky> ages*
[12:01] <amachu> svaksha appear to have some time problem
[12:01] <amachu> hmm..
[12:01] <persia> Nor I lousygarua, although it used to be often.
[12:01] <elky> she's been on freenode for the whole of 20 seconds this month afaict
[12:02] <amachu> Hew is in #ubuntu-au
[12:02] <elky> amachu, hew is here now
[12:02] <amachu> Hew: Hey :-)
[12:02] <Hew> Hi everyone
[12:03] <TheMuso> Evening he.
[12:03] <TheMuso> evening Hew.
[12:03] <amachu> Hew: are you prepared for today?
[12:03] <amachu> Sorry for the confusion, the wiki states 01-Oct-08
[12:03] <Hew> Yes, that is confusing :P
[12:03] <Hew> I am prepared nonetheless
[12:03] <amachu> as per routine its tueday, today
[12:04] <Hew> ah, ok
[12:04] <amachu> thats great...
[12:04] <amachu> persia: elky: TheMuso: persia: shall we start then..
[12:04] <TheMuso> amachu: Yes, lets.
[12:05] <amachu> Hew: Sorry for the confusion again. Please go ahead introducing yourself and your contributions for Ubuntu..
[12:05] <elky> yes, waiting
[12:06] <Hew> No worries. I'm Hew McLachlan from Sydney. I've been using Ubuntu since Dapper and have been contributing in various areas since the beginning of this year.
[12:07] <Hew> I've mainly been involved with bug triage. I started in the Ubuntu BugSquad and I'm now a member of Ubuntu Bug Control.
[12:09] <Hew> I believe I've made a significant contribution to Ubuntu through the number and quality of bugs I have triaged, as well as the other areas I've been involved in such as support and reporting bugs, and recently, en_AU translations.
[12:11] <Hew> I started cleaning up packages like xsane which had been neglected for a long time and were full of New/Undecided bugs, so that gave me a good start in learning how to triage from the bottom up.
[12:12] <amachu> that great that you file five bugs  a day. Apart from that would like to know your association with Austraian LoCo too..
[12:13] <Hew> I haven't had much to do with the Australia LoCo, apart from making the occasional passing comment in #ubuntu-au about a discussion.
[12:13] <Hew> I'm most active in #ubuntu-bugs
[12:14] <amachu> ok
[12:14] <persia> Hew: You mention a long-term goal of having Ubuntu be 100% free software.  Do you think this is best pursued through work to free existing software, or to find replacement software?
[12:16] <Hew> persia: A combination of both. If you look at the AMD/ATI situation, they are now developing over source drivers themselves which is a great success for FOSS. It will be hard to do the same with Nvidia, but by developing open source 3D Nvidia drivers I think will put pressure on Nvidia to produce something themselves.
[12:17] <persia> Hew: Have you been involved in any of these discussions?
[12:19] <Hew> persia: Not as part of Ubuntu, no. I keep an eye on what's happening and discuss it offline though. I would be interested in getting involved and having a say.
[12:19] <Hew> I'm not a developer so I don't really have technical solutions to these problems.
[12:21] <amachu> elky: TheMuso: questions?
[12:21] <TheMuso> Not from me.
[12:22] <amachu> and Hew do you have people here for you?
[12:22] <elky> Hew, have you considered getting into packaging at all?
[12:22] <elky> whups, sorry amachu
[12:23] <Hew> amachu: No I don't.
[12:23] <Hew> elky: Yes I have. I submitted a patch to a debian/control file for prboom.
[12:24] <elky> is that part of a larger plan?
[12:24] <Hew> elky: I've also played around with pbuilder and looked through the MOTU contributing wiki pages
[12:24] <Hew> elky: Yes, I've thought about maybe joining backports or something
[12:25] <Hew> elky: I think I've got my name on a couple of packages in Intrepid
[12:25] <elky> which ones?
[12:25] <Hew> elky: hmm, fretsonfire from memory..
[12:26]  * Hew has a quick look
[12:26] <persia> Hew: Given the packages for which you've submitted patches, if you are interested in development, you may also want to get in touch with the Games team.
[12:27] <Hew> persia: Yea, I'm able to do things like modifying the debian/control files, but C coding is a bit over my head for now. I'll look into it :-)
[12:29] <Hew> fretsonfire 1.2.512.dfsg-3 has my name as Changed-By
[12:29] <amachu> and elky appear to be in your time zone ;-)
[12:29] <TheMuso> As am I.
[12:29] <Hew> and same with game-data-packager 18 :P That's the two.
[12:30] <amachu> is lifeless there?
[12:30] <elky> amachu, unfortunately there is only vague familiarity with the nick from him sitting in the loco channel. other than that i dont really know anything about hew
[12:32] <elky> amachu, lifeless is idle 35 minutes
[12:32] <amachu> ok
[12:32] <persia> Well, I always like testmonials or support from other members, which we don't have today.  I'm tempted to +1 based on at least three months of activity within ubuntu-bugcontrol, and some previous activity, and I like the work with en_au translations, but I'm still a little borderline.
[12:33] <persia> Could others who use en_AU comment on how useful it is to have en_AU fully translated?
[12:33] <amachu> Hew: is it because that you are here today
[12:33] <amachu> and you couldn't bring people to support, since the wiki said its tomorrow?
[12:34] <TheMuso> persia: I must admit I don't really pay attention to translations, at it usually comes down to slight differences in spelling, so don't bother checking.
[12:34] <elky> persia, from my understanding of en_au, it's only a matter of small differences such as trash/rubbish/garbage
[12:35] <elky> and location names possibly
[12:35] <Hew> amachu: No, I don't have specific people for support. I generally just ask questions to the channel and give answers back.
[12:35] <persia> Hmm.  I'm maybe +0.6 then.  With a couple testimonials, or cheerleaders, I'd be +1.
[12:36] <Hew> en_AU translations aren't that important I guess, but see "color" all the time annoys me ;-)
[12:36] <Hew> seeing*
[12:36] <persia> The work is good, and it's both significant and sustained, but the involvement with other individuals in the community seems unsupported (it may be present, but it's not currently visible from available information).
[12:37] <james_w> I find Hew to be an active and skilled bug triager, and he is a valuable member of that community.
[12:37] <persia> RIght.  +1 from me then.
[12:37] <james_w> sorry I'm late :-)
[12:37] <Hew> james_w: Thank you :-)
[12:38] <amachu> Hew: +1 from me too
[12:38] <amachu> and elky, TheMuso?
[12:39] <TheMuso> Knowing that it takes some work to become a good bug triager, and having heard a testimonial from james_w about Hew's work, Im +1 as well.
[12:40] <elky> i'm +0. while i'm pleased with 3 months of 5-a day, I believe that 4 months is too quick a time to be considered sustained.
[12:40] <elky> (4 mths being first team join)
[12:40] <amachu> TheMuso: also for getting prepared immediatly knowing its today and not tomorrow..
[12:41] <TheMuso> amachu: What about it?
[12:41] <amachu> TheMuso: I added one more reason sticking to yours :-)
[12:41] <persia> elky: What do you think is a sensible time guideline?  I'm still operating against the two-month guideline from long ago.
[12:43] <amachu> elky: any other reason other than the duration of involvement?
[12:45] <amachu> elky: there?
[12:45] <elky> persia, i consider 6 months to be sustained. 2 months goes past in a blink. amachu im not really sure, to be honest.
[12:46] <persia> elky: OK.  And from first team join?  (Looks like 2008-05-03 in this case)
[12:46] <persia> Or from first restricted team join?
[12:50] <amachu> elky: its true that 2-3 months goes in a blink..
[12:50] <amachu> the contributions from Hew are promising, I feel
[12:50] <persia> Although 2-3 months is the guideline listed at https://wiki.ubuntu.com/Membership
[12:50] <elky> amachu, which is why i'm reserving now. it's borderline
[12:51] <persia> If that's not the guideline we use, the page ought be updated.
[12:51] <elky> persia, if we're just here to check boxes then why have multiple of us. i was asked my opinion and i gave it.
[12:52] <persia> elky: I'm not arguing with your opinion.  I'm not asking you to change it.
[12:52] <persia> I also think 2 months is very short.  I'm just trying to understand what seems right, and make sure that applicants are receiving appropriate guidance.
[12:53] <amachu> persia: elky: I hope, then 3:1 should favour Hew, which all of us will agree.
[12:53] <amachu> with a note to Hew to take elky's observations carefully and contribute continuosly
[12:53] <elky> amachu, that's democracy. im not going to argue you in to changing your opinions, which is why i'm perplexed we're persisting the point
[12:54] <persia> Right.  We ought discuss it at some point.  For those of us who find two months fast, it may be sensible to talk with other RMBs and maybe the CC to determine if that remains the right guidance.
[12:55] <elky> this is now an hour since we started, too.
[12:55] <persia> Hew: In addition to your bug triage work, I'd encourage you to get involved with the rather active ubuntu-au crowd: there's a fair bit going on there.
[12:55] <persia> elky: Sure.  Next week works for me.
[12:55] <Hew> persia: Will do, I'll speak up more and find out what's going on.
[12:56] <persia> amachu: Could we add that to the agenda: whether the current guidance of two months is sufficient?
[12:56] <amachu> fine then. Let me welcome Hew and ask him to take into consideration elky's observation
[12:56] <amachu> persia: yes.
[12:56] <amachu> persia: should we add that to our agenda? or CC's?
[12:57] <Hew> amachu: Thanks! I will stay active and look at other areas I can become involved in.
[12:57] <persia> I'm not tempted to add it to CC just because I don't have more than a weak feeling that 2 months can be very quick.  If someone else wants to present, that would be fine.
[12:57] <elky> well, neither cc timing fits me
[12:58] <persia> If we add it to ours, either we can collect discussion items to present to the CC, or decide most of us don't have the feeling elky and I share, and defer it.
[12:58] <amachu> i will check that and share it in the mailing list
[12:58] <persia> elky: Not even the one that conflicts with this meeting?
[12:58] <elky> persia, well no, i often make use of the extra meeting-free evenin
[12:59] <persia> elky: Heh.  I can well understand that :)
[13:00] <amachu> persia: We will add it to our agenda first.
[13:00] <amachu> and discuss next week.. later depending on availabity of any one of us we shall take it to CC
[13:01] <amachu> I will also inform Arc Riley that the meeting is not tomorrow and its next week...
[13:02] <amachu> Hew: Welcome againg and looking forward to a continuos contribution from you with more involvement with LoCo team :-)
[13:02] <persia> OK.  We're done then?
[13:02] <amachu> persia: I hope so. Is there anything else?
[13:03] <amachu> TheMuso: ??
[13:03] <amachu> elky: ?
[13:03] <TheMuso> Nope.
[13:03] <Hew> amachu, persia, elky, TheMuso, james_w: Thanks everyone, I look forward to contributing!
[13:03] <amachu> elky: are you there?
[13:04] <amachu> Hew: Keep rocking :-)
[13:04] <elky> amachu, yep
[13:05] <amachu> elky: shall we wind up for the day?
[13:05] <elky> yep
[13:05] <TheMuso> Thanks folks.
[13:05] <amachu> thank you every one for participating.
[13:06] <amachu> our next meeting will be on 07 Oct 08
[13:06] <elky> sure it's the 7th?
[13:06] <TheMuso> Yes its the 7th.
[13:06] <amachu> elky: yes
[13:06] <amachu> ;-)
[13:06]  * elky ducks
[13:06] <amachu> Cheers!
[13:07] <leoquant> @schedule amsterdam
[15:54] <freeflying> @schedule
[15:55] <freeflying> @schedule shanghai
[15:57] <zul> @schedule montreal
[15:59]  * mathiaz waves
[15:59] <nealmcb> o/
[15:59] <kirkland> \o/
[15:59] <sommer> hey all
[16:00] <Koon> o/
[16:00] <zul> hello
[16:00] <dendrobates> \oo/
[16:01] <nijaba> o/
[16:01] <soren> o/&
[16:01] <kirkland> * dendrobates is a siamese twin?
[16:01] <dendrobates> yup
[16:01] <kirkland> and *soren is holding a bong?
[16:01] <mathiaz> all right - let's get started
[16:01] <mathiaz> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is mathiaz.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <soren> kirkland: Maybe.
[16:02] <soren> kirkland: :P
[16:02] <mathiaz> Today's agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:02] <nealmcb> I thought dendrobates had spiked sideburns
[16:02] <mathiaz> Previous meeting minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20080923
[16:02] <mathiaz> [TOPIC] Ubuntu vm builder
[16:02] <MootBot> New Topic:  Ubuntu vm builder
[16:03] <mathiaz> soren: what's new there ?
[16:03] <soren> New version uploaded with lots fixes in it.
[16:03] <soren> Erm..
[16:03] <soren> No big news, I'm afraid.
[16:03] <mathiaz> nijaba: how is the tutorial update going ?
[16:04] <nijaba> mathiaz: I just completed it, fixing/finding a few bugs as I go
[16:04] <mathiaz> soren: IIRC you've added xen support to vmbuilder
[16:04] <nijaba> mathiaz: but I think that, apart from a few changes, the general content is there and I'd love to get some feedback
[16:04] <mathiaz> soren: do you have access to a xen environment to do the testing ?
[16:05] <mathiaz> nijaba: url ?
[16:05] <soren> mathiaz: That was weeks ago, though.
[16:05] <soren> mathiaz: Yes, I have Xen running inside a KVM instance :)
[16:05] <zul> soren: scarey
[16:05] <nijaba> has not changed: https://help.ubuntu.com/community/JeOSVMBuilder
[16:05] <soren> mathiaz: zul and I have been trying to get Xenner to be useful, but it's not working out very well.
[16:05] <nijaba> Xenner?
[16:06] <soren> Xenner is a twisted version of KVM that can run Xen paravirt instances.
[16:06] <zul> xen built ontop of kvm
[16:06] <mathiaz> soren: is there support for vmware in vmbuilder ?
[16:06] <zul> soren: a version of it will be in the next version of xen
[16:06] <soren> It's rather... umm... interesting *cough*.
[16:06] <soren> mathiaz: There is, yes.
[16:07] <mathiaz> soren: do you have access to vmware environment to test it ?
[16:07] <nijaba> but no virtual box yet, I think that's the main one missing
[16:07] <soren> mathiaz: Nope.
[16:07] <nijaba> (even though it is not a priority)
[16:07] <soren> nijaba: Right. Someone asked me about that yesterday.
[16:08] <mathiaz> soren: are all product of vmware supported ?
[16:08] <mathiaz> soren: like ESX, -server, etc... ?
[16:08] <soren> nijaba: I told him that if he could explain how to turn a set of raw images and some settings (amount of ram, cpu's, etc.) into a vbox instance, I'd be happy to implement it.
[16:08] <soren> nijaba: We'll see how it goes.
[16:08] <soren> mathiaz: I forget the details right now.
[16:09] <soren> mathiaz: It should support whatever ubuntu-vm-builder supported.
[16:09] <soren> If it doesn't, that's a bug that needs fixing.
[16:09] <nijaba> mathiaz: I am not sure we can support ESX fully with what qemu-img offers
[16:09] <mathiaz> soren: ok - anyway testing in vmware product is welcome.
[16:09] <nijaba> mathiaz: was the same for uvb
[16:09] <mathiaz> nijaba: ok.
[16:10] <mathiaz> it may be usefull to figure out which products/technologies are supported by vm-builder.
[16:10] <nijaba> player, workstation and server. For esx, it needs a manual conversion IIRC
[16:11] <nijaba> tools are provided by VMware
[16:11] <mathiaz> nijaba: thanks.
[16:11] <mathiaz> [TOPIC] Review ServerGuide for Intrepid
[16:11] <MootBot> New Topic:  Review ServerGuide for Intrepid
[16:11] <mathiaz> sommer: did you update the virtualization section
[16:11] <mathiaz> ?
[16:12] <sommer> mathiaz: I added a couple of lines about xen, but I'm not sure it's quite where it needs to be
[16:12] <sommer> mathiaz: it'll be updated by SF though
[16:13] <nijaba> sommer: pointer to what you added?
[16:13] <mathiaz> zul: could you take a look at the seciont ?
[16:13] <mathiaz> zul: could you take a look at the virtualization section ?
[16:13] <zul> mathiaz: yep
[16:13] <sommer> nijaba: http://doc.ubuntu.com/ubuntu/serverguide/C/ubuntu-vm-builder.html
[16:13] <mathiaz> zul: ^^
[16:14] <mathiaz> [ACTION] zul to do review of the virtualization of the server guide.
[16:14] <MootBot> ACTION received:  zul to do review of the virtualization of the server guide.
[16:14] <mathiaz> sommer: nijaba: shouldn't the JeOS section be removed ?
[16:15] <nijaba> mathiaz: or updated using what I just produced on the wiki?
[16:15] <dendrobates> mathiaz: or changed.
[16:15] <mathiaz> or at least updated as there won't be JeOS iso
[16:15] <mathiaz> dendrobates: IIUC JeOS is now an option in the -server iso
[16:15] <soren> That's the idea, yes.
[16:15] <nijaba> mathiaz: or an option in vmbuilder
[16:16] <mathiaz> how do you get to install a JeOS from -server ?
[16:16] <nijaba> (as soon as we find a virtual kernel for intrpid)
[16:16] <nijaba> mathiaz: press F4 at first screen
[16:17] <mathiaz> which kernel flavour is currently installed ?
[16:17] <nijaba> for some reason, there is no linux-image-virtual kernel available in intrepid ATM
[16:17] <mathiaz> since -virtual doesn't exist
[16:17] <soren> Sure it does.
[16:17] <nijaba> mathiaz: -server
[16:17] <soren> I've filed a bug against linux-meta about the missing linux{,-image}-virtual packages.
[16:18] <dendrobates> soren: have you sent an email to pete about it?
[16:18] <soren> There *is* a virtual kernel flavour.
[16:18] <soren> dendrobates: Umm. No?
[16:18] <nijaba> soren: and is the 64bit version available as well?
[16:18] <soren> nijaba: Yes.
[16:18] <nijaba> so the only thinkg misssing is the meta packages....
[16:18] <soren> yes.
[16:18]  * nijaba puts too many letters...
[16:19] <mathiaz> soren: once the -virtual- packages are there, is there anything that needs to be changed in the installer to pick itup ?
[16:19] <soren> dendrobates: linux-image-2.6.27-4-virtual | 2.6.27-4.6 | intrepid/universe | amd64, i386
[16:19] <soren> Whoops, that wasn't for dendrobates.
[16:19] <soren> Whuh... Universe?
[16:19] <nijaba> mathiaz: some server-ship seeding?
[16:19] <soren> Yeah, we need to seed it.
[16:19] <mathiaz> soren: since as of now -server is installed in Jeos
[16:20] <soren> It needs seeding, but first a metapackage.
[16:20] <mathiaz> soren: right - and the installer will automatically choose it
[16:20] <soren> mathiaz: Erm.. No.
[16:20] <soren> mathiaz: Not the -virtual kernel.
[16:20] <dendrobates> I want to make sure someone looks at the bug.
[16:21] <mathiaz> soren: ok - so -virtual- needs to be seeded + the installer has to be modified.
[16:21] <soren> mathiaz: I'm working on a "detect which virtual environment I'm in, if any" utility.
[16:21] <soren> I'm going to get that added to base-installer for Jaunty.
[16:21] <mathiaz> soren: for intrepid or beyond ?
[16:21] <soren> mathiaz: I'm not sure about changing the installer.
[16:22] <soren> The option you get in isn't called "JeOS". It's called "Minimal install".
[16:22] <mathiaz> soren: ok - so that means we still need to fix or at least look into the JeOS option for the intrepid installer
[16:22] <soren> Which, apart from the kernel choice, is the same thing.
[16:22] <nijaba> soren, in fact, it is not a real JeOS iso replacement...
[16:22] <soren> ..but it's preseedable, which was the original requirement (back in the gutsy days).
[16:22] <soren> nijaba: -v
[16:23] <nijaba> Well, the JeOS iso would install the -virtual kernel by default, so picking minimal install is not a replacement for it
[16:24] <mathiaz> nijaba: so the minimal install for -server intrepid isos installs the same set of packages than JeOS ?
[16:25] <mathiaz> nijaba: what's missing is the -virtual- kernel packages for now ?
[16:25] <soren> nijaba: That's what I just said?
[16:25] <soren> 15:22:19 < soren> Which, apart from the kernel choice, is the same thing.
[16:25] <soren> mathiaz: Yes, apart from the kernel, the choice of packages is (or should be) the same.
[16:26] <mathiaz> soren: ok.
[16:26] <mathiaz> let's move on.
[16:26] <soren> Let's.
[16:26] <mathiaz> sommer: anything else on the server guide ?
[16:26] <sommer> so the jeos section needs updated, and probably the installation section?
[16:26] <mathiaz> sommer: I've given you some feedback on the ldap serction
[16:26] <sommer> mathiaz: yep... still need to adjust that
[16:27] <dendrobates> mathiaz: did you give sommer feedback on the support section, that we discussed?
[16:27] <sommer> mathiaz: was the ldapadd instead of slapadd the only thing?
[16:27] <mathiaz> sommer: not yet
[16:27] <mathiaz> dendrobates: not yet.
[16:27] <dendrobates> mathiaz: you had wanted some changes, that I agreed with.
[16:28] <mathiaz> [ACTION] mathiaz to update the support section of the server guide
[16:28] <MootBot> ACTION received:  mathiaz to update the support section of the server guide
[16:28] <mathiaz> sommer: yes
[16:28] <sommer> mathiaz: cool
[16:28] <mathiaz> sommer: I still wanna go through the rest of the section and test it.
[16:28] <mathiaz> sommer: there are some sub-sections about replication and so on.
[16:29] <mathiaz> sommer: I wonder if it's too advanced for the server guide.
[16:29] <sommer> mathiaz: ya, cn=config does add some more complexity
[16:29] <mathiaz> sommer: we could probably mention that it exists and point to the openldap guide
[16:29] <mathiaz> sommer: upstream documentation is good
[16:30] <sommer> mathiaz: I think it's pretty important to have replication in... having only a single LDAP server on a network is sort of scary
[16:31] <mathiaz> [ACTION] sommer to update the JeOS and installation section
[16:31] <MootBot> ACTION received:  sommer to update the JeOS and installation section
[16:31] <mathiaz> sommer: right - IIRC upstream documentation may lack some real world ldif files to setup replication.
[16:31] <mathiaz> sommer: I'll go through the section and test it
[16:32] <sommer> mathiaz: ya, and it's not really very clear on adding schema ldif files
[16:32] <mathiaz> sommer: anything else ?
[16:32] <sommer> mathiaz: I think that's it
[16:32] <mathiaz> sommer: great - thanks !
[16:32] <mathiaz> [TOPIC] nagios3 in main
[16:32] <MootBot> New Topic:  nagios3 in main
[16:32] <mathiaz> Koon: ^^ ?
[16:32] <mathiaz> Koon: I think it's fixed now ?
[16:33] <Koon> mathiaz: I posted the MIR, which wasn't really needed, then nagios3 was promoted
[16:33] <Koon> and you added it to the server-ship seed
[16:33] <mathiaz> and it's on the -server cd now ! :D
[16:33] <nijaba> server-ship?
[16:33] <mathiaz> nijaba: yes
[16:33]  * nijaba wonders why, but fine
[16:34] <mathiaz> nijaba: nagios2 was there
[16:34] <nijaba> mathiaz: ah, makes sense then
[16:34] <soren> Well, it wasn't, actually.
[16:34] <Koon> yep
[16:34] <mathiaz> nijaba: I've just s/nagios2/nagios3/
[16:34] <soren> ..but that was a mistake :)
[16:34] <Koon> soren: tss
[16:34] <mathiaz> [TOPIC] Ubuntu Server survey
[16:34] <MootBot> New Topic:  Ubuntu Server survey
[16:34] <mathiaz> nijaba: how is it going ?
[16:35] <nijaba> it is doing great
[16:35] <nijaba> more than 2000 full replies so far
[16:35] <nealmcb> :)
[16:35] <sommer> wow
[16:35] <mathiaz> nijaba: when do you plan to close the survey ?
[16:35] <nijaba> we get about 1/3 of the respondant that do not complete the survey, but that was expected
[16:36] <nijaba> mathiaz: result will be published before UDS, so I intend to close it last week of november
[16:36]  * nijaba looking for people knowing how to use a SPSS type tool
[16:36] <mathiaz> nijaba: seems that the marketing plan is working well.
[16:37] <nijaba> mathiaz: yes, it is.
[16:37] <mathiaz> anyone that wants to blog about it is welcome.
[16:37] <nijaba> there are also some items left to do in the launch plan
[16:37] <mathiaz> it was announced last thursday - and there is a digg link IIRC
[16:37] <nijaba> yes, but that is not getting too much digging
[16:37] <kirkland> please splat the digg link here, now
[16:38] <kirkland> i'll digg+1 it :-)
[16:38] <nijaba> http://digg.com/linux_unix/Ubuntu_Server_survey_launched
[16:38] <MootBot> LINK received:  http://digg.com/linux_unix/Ubuntu_Server_survey_launched
[16:38] <kirkland> done
[16:38] <nealmcb> nijaba: I've played with R in the past - very powerful, if confusing.  scipy also does a lot
[16:39] <kirkland> i'll blog something too
[16:39] <nijaba> nealmcb: are you voluntering to help on the analysis?
[16:39] <nijaba> ;)
[16:39] <mathiaz> [ACTION] kirkland to blog about the server survey
[16:39] <MootBot> ACTION received:  kirkland to blog about the server survey
[16:40]  * nealmcb gets a digg in
[16:40] <nealmcb> nijaba: yes
[16:40]  * nijaba hugs nealmcb
[16:40] <nealmcb> I'm not an expert with stats or surveys, but will do what I can
[16:40] <mathiaz> nijaba: great - anything else on the survey ?
[16:41] <nijaba> nope...
[16:41] <mathiaz> [TOPIC] Beta Freeze
[16:41] <MootBot> New Topic:  Beta Freeze
[16:41] <mathiaz> so we're in beta freeze and the -server isos for beta have been produced.
[16:41] <mathiaz> http://iso.qa.ubuntu.com/ is used to track the tests.
[16:41] <MootBot> LINK received:  http://iso.qa.ubuntu.com/ is used to track the tests.
[16:41]  * ivoks o/
[16:42] <mathiaz> on a related note, partman-auto-raid has been promoted to main and is now available on the iso
[16:42] <zul> what does that do again?
[16:42] <mathiaz> so preseeded installs can now setup a RAID system
[16:42] <zul> ah
[16:43] <kirkland> \o/
[16:43] <mathiaz> It requires some testing though.
[16:43] <ivoks> iirc, it is usable
[16:43] <ivoks> at least it was when i worked on that... a year ago (or more) :)
[16:43] <mathiaz> ivoks: well - it has never been tested in ubuntu.
[16:43] <ivoks> right
[16:44] <mathiaz> ivoks: It works in debian.
[16:44] <nijaba> an is the option to have a sane boot degraded mode preseedable as well?
[16:44] <nijaba> s/an/and
[16:44] <soren> Yes. It's been the default for years.
[16:45] <soren> :p
[16:45] <nijaba> :P
[16:45] <mathiaz> nijaba: kirkland implemented it - he should know about it.
[16:46] <kirkland> mathiaz: sadly, i have little experience with preseeding, so I don't know
[16:46] <nijaba> kirkland: is it a debconf question?
[16:46] <kirkland> nijaba: yup
[16:46] <soren> kirkland: presseding means answering debconf questions ahead of time.
[16:46] <ivoks> kirkland: you are so lucky... :)
[16:46] <nijaba> so it should work fine
[16:46] <mathiaz> kirkland: ok - so it's preseedable.
[16:46] <kirkland> awesome
[16:47] <soren> For bonus points, someone should tweak kickseed to handle this..
[16:47]  * nealmcb pats kirkland on the back
[16:47] <ivoks> that shouldn't be too hard
[16:47] <nijaba> soren: err... kickstart?
[16:47] <soren> kickseed.
[16:47] <ivoks> no, seed
[16:47] <ivoks> kickstart doesn't know anything about preseeding
[16:47] <mathiaz> nijaba: kickseed is the name of the kickstart implementation for the Ubuntu installer
[16:48] <nijaba> ivoks: yup, but you can add preseeds to it
[16:48] <soren> nijaba: kickseed is an installer component that lets you pass a kickstart file to d-i and then it translates it into the corresponding preseed values.
[16:48]  * nijaba used it without know its name...
[16:48] <mathiaz> ivoks: kickseed has a hook to add preseed command in the kickstart file
[16:49]  * nijaba confirms that it is VERY usefull
[16:49] <ivoks> ok... i always used kickstart file + preseed file - i guess i'm outdated :)
[16:50] <mathiaz> so if you've got some spare server hardware, testing the -server iso for Beta is more than welcome!
[16:50] <mathiaz> Beta is schedule for Thursday.
[16:51] <ivoks> ok :)
[16:51] <mathiaz> [TOPIC] Open Discussion
[16:51] <MootBot> New Topic:  Open Discussion
[16:51] <mathiaz> anyone wants to add anything ?
[16:51] <ivoks> yes?
[16:51] <ivoks> am i allowed to twist arms of kernel team?
[16:51] <ivoks> :)
[16:52] <ivoks> we have very broken drbd implementation in intrepid
[16:52] <mathiaz> ivoks: on your behalf or on behalf of the server team ?
[16:52] <ivoks> this requires changes in kernel and new user space tools
[16:52] <ivoks> well, server team
[16:52] <nijaba> great calendar to add for the up to date release schedule: 	http://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
[16:52] <ivoks> the thing is that we have to ship release candidate of drbd 2.8.7
[16:52] <mathiaz> ivoks: what is required on the kernel side ?
[16:53] <ivoks> since stable release doesn't work on 2.6.27, and changes are huge
[16:53] <mathiaz> ivoks: do you have a bug number?
[16:53] <ivoks> this also means that we'll have user space tools from debian experimental
[16:53] <ivoks> yes
[16:54] <ivoks> bug #271254
[16:54] <ivoks> i've been working on this for last 3-4 days and i have a working solution - drbd 2.8.7~rc1
[16:55] <ivoks> http://www.grad.hr/~ivoks/0001-UBUNTU-drbd-New-upstream-prerelease-2.8.7-rc1.patch
[16:55] <MootBot> LINK received:  http://www.grad.hr/~ivoks/0001-UBUNTU-drbd-New-upstream-prerelease-2.8.7-rc1.patch
[16:55] <ivoks> this is a patch for kernel
[16:55] <mathiaz> ivoks: I'm confused by the version numbers.
[16:55] <zul> i had a look at the kernel patch and it looks fine to me
[16:55] <mathiaz> ivoks: 2.8.7 or 8.2.7 ?
[16:55] <ivoks> 8.2.7
[16:55] <zul> mathiaz: 8.2.7
[16:55] <ivoks> sorry, my mistake
[16:55] <ivoks> i'll fix that
[16:56] <mathiaz> ivoks: as of now, 8.2.6 doesn't work in 2.6.27 ?
[16:56] <ivoks> correct
[16:56] <ivoks> opensuse has the same problem
[16:56] <nealmcb> ivoks: thanks for figuring all that out!
[16:56] <mathiaz> ivoks: could it be possible to fix 8.2.6 ?
[16:56] <mathiaz> ivoks: or 8.2.7 is the only viable option ?
[16:57] <zul> basically what happened is that we have 8.0.12 in the archive and the kernel has 8.2.6 which doesnt work well together and if you use 8.2.6. kernel/user then it wont work as well
[16:57] <ivoks> mathiaz: i've looked at commit, for which drbd guys say that fixes the issue
[16:57] <ivoks> it simply depends on too many changes to just go cherry picking
[16:58] <ivoks> in my opinoion, 8.2.7 is a way to go
[16:58] <mathiaz> zul: ok - so 8.2.6 is broken - 8.2.7rc1 works
[16:58] <zul> mathiaz: yes
[16:59] <mathiaz> ivoks: could the kernel be downgraded to 8.0.12 ?
[16:59] <ivoks> i haven't tested 8.0.12 with 2.6.17
[16:59] <zul> mathiaz: Ive talked to kernel guys about that before I got ivoks involved and they didnt think it was a good idea
[17:00] <mathiaz> right - so it seems that 8.2.7rc1 is the best option as the current situation is broken
[17:00] <ivoks> right
[17:01] <nealmcb> zul: and thanks to you too...  looks like it might be one of those costs of going with the 2.6.27 kernel
[17:01] <ivoks> we can do this changes after beta is out...
[17:01] <mathiaz> ivoks: do you have 8.2.7 tools in a ppa ?
[17:01] <dendrobates> ivoks: is there a bug #
[17:01] <ivoks> nealmcb: yes, it's exactly that...
[17:01] <mathiaz> dendrobates: https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/271254
[17:01] <ivoks> mathiaz: no, but i'm working on it... upstream alredy provides debian/, so i'll just compare to our and debian source
[17:02] <mathiaz> ivoks: you've mentionned debian experimental.
[17:02] <ivoks> yes
[17:02] <ivoks> mathiaz: debian experimental has 8.2.6
[17:02] <mathiaz> ivoks: I think the key point here is to have the tools in a PPA so that we can show that 8.2.7 is working correctly.
[17:02] <ivoks> mathiaz: i agree
[17:03] <ivoks> mathiaz: i have 8.2.6 in my ppa, but i'll move it to 8.2.7 today
[17:03] <mathiaz> ivoks: excellent. then once we're out of beta, we can update the kernel.
[17:03] <mathiaz> ivoks: IIUC you've also the kernel part ready ?
[17:04] <mathiaz> ivoks: ie a git branch ready ?
[17:04] <ivoks> mathiaz: correct
[17:04] <ivoks> yes
[17:04] <ivoks> http://www.grad.hr/~ivoks/0001-UBUNTU-drbd-New-upstream-prerelease-2.8.7-rc1.patch
[17:04] <MootBot> LINK received:  http://www.grad.hr/~ivoks/0001-UBUNTU-drbd-New-upstream-prerelease-2.8.7-rc1.patch
[17:04] <zul> ivoks: just send the patch off to the kernel-t-eam mailing list is is the proper procedure
[17:04] <mathiaz> ivoks: zul: is it possible to upload a modified kernel to a PPA ?
[17:04] <ivoks> why not?
[17:05] <mathiaz> ivoks: I don't know - that's why I'm asking :D
[17:05] <zul> mathiaz: it can be done sure...
[17:05] <ivoks> if not, i can setup archive outside ppa
[17:05] <mathiaz> ivoks: to point is to get wider testing ASAP
[17:05] <mathiaz> ivoks: KernelFreeze will be in two weeks for Intrepid.
[17:05] <ivoks> i know
[17:05] <mathiaz> ivoks: so we won't have that many uploads to test/fix things.
[17:05] <ivoks> sorry, i didn't have time untill a week ago :(
[17:05] <zul> mathiaz: its best to send off the patch asap
[17:06] <mathiaz> zul: ok
[17:06] <ivoks> zul: with fixed typo
[17:06] <mathiaz> [ACTION] ivoks to send the drbd patch to the ubuntu-kernel mailing list
[17:06] <MootBot> ACTION received:  ivoks to send the drbd patch to the ubuntu-kernel mailing list
[17:06] <zul> ivoks: yep
[17:07] <mathiaz> [ACTION] ivoks to upload 8.2.7 tools to a PPA
[17:07] <MootBot> ACTION received:  ivoks to upload 8.2.7 tools to a PPA
[17:07] <mathiaz> ivoks: ^^ that will help for sponsoring
[17:07] <ivoks> and kernel source
[17:07] <ivoks> i know
[17:08] <ivoks> easier to track changes
[17:08] <mathiaz> ivoks: excellent ! Thanks for the good work
[17:08] <mathiaz> Anything else to add ?
[17:08] <ivoks> yes :)
[17:08] <ivoks> bacula :)
[17:08] <ivoks> bacula in hardy isn't in very good shape
[17:09] <ivoks> we've missed a .1 release cause of one bug
[17:09] <ivoks> upstream claims that bug is fixed, but our bug reporter claims it isn't
[17:09] <mathiaz> ivoks: .1 - you mean 8.04.1 ?
[17:09] <ivoks> right
[17:09] <mathiaz> ivoks: well - we can still fix things in hardy.
[17:10] <ivoks> what's the procedure if our bug reporter doesn't reply to bug report, while upstream claims that bug is fixed?
[17:10] <nijaba> ivoks: I would tend to beleive waht kern said and check if the 2 patches he mentioned were actually applied
[17:10] <ivoks> since, for SRU, we need validation-confirmed
[17:10] <ivoks> and there's no one to confirm it :)
[17:10] <mathiaz> ivoks: what's the bug number ?
[17:11] <ivoks> just a second...
[17:11] <mathiaz> ivoks: for SRU we also need a test case - so that we can reproduce it
[17:11] <ivoks> bug #227613
[17:13] <mathiaz> ivoks: hm - it seems that we have test case that is repoducable
[17:14] <mathiaz> ivoks: zul: were you able to reproduce it or not ?
[17:14] <ivoks> well, it just seems
[17:14] <ivoks> neither can i or upstream reproduce this bug :)
[17:14] <zul> mathiaz: no i wasnt
[17:15] <mathiaz> ivoks: well - in that case, we can only rely on the reporter or one of the tester.
[17:15] <ivoks> and the bug reporter on bacula's buglist confirmed that this patch solved the issue
[17:16] <mathiaz> ivoks: ok - it seems that it's a corner case though
[17:16] <ivoks> ok, so we wait for bug reporter to confirm it is fixed?
[17:16] <mathiaz> ivoks: in this case we rely on the rporter
[17:16] <ivoks> ok
[17:16] <mathiaz> ivoks: yes - I'd proceed that way.
[17:17] <ivoks> that's what i tought... :)
[17:17] <mathiaz> ok - we're over time now.
[17:17] <mathiaz> Anything else ?
[17:18] <mathiaz> [TOPIC] Agree on next meeting date and time
[17:18] <MootBot> New Topic:  Agree on next meeting date and time
[17:18] <mathiaz> next week, same time, same place ?
[17:18] <ivoks> ok
[17:18] <sommer> works for me
[17:19] <mathiaz> great - so see ya all next week, same time, here.
[17:19] <mathiaz> happy beta testing all !
[17:19] <mathiaz> #endmeeting
[17:19] <MootBot> Meeting finished at 11:19.
[17:19] <ivoks> \o/
[17:19] <sommer> thanks mathiaz, later on all
[17:19]  * soren kicks Mootbot into a resonable timezone
[17:20] <soren> 11:19... pffffft!
[17:20] <nealmcb> soren: yeah - us central time - huh....
[17:21] <nealmcb> now mountain time - that would be good :)
[17:26]  * soren shakes his head in disbelief
[17:27] <soren> Swatch internet time.
[17:27] <alex3f[ubuntu-ro> 18:26 CET
[19:05] <juliux> @schedule berlin
[19:15] <boredandblogging> juliux: might be a bit late for the meeting
[19:15] <juliux> boredandblogging: hm?
[19:15] <juliux> ok
[19:52] <GiorgosL[GR]> hello everyone
[19:53] <juliux> hi GiorgosL[GR]
[19:53] <juliux> popey: boredandblogging ping
[19:54] <elendil> hi
[19:54] <juliux> hi elendil
[20:00] <juliux> welcome to the lococouncil meeting we are waiting atm for more council members
[20:01] <Ow1> OK. I'm here for representing Romanian LoCo team. Did we qualify for this meeting?
[20:01] <manuelciosici> hey Ow1
[20:01] <juliux> hi Ow1 yes you are on the agenda
[20:02] <Ow1> ok
[20:06] <boredandblogging> i'm in a meeting
[20:06] <boredandblogging> brb
[20:06] <boredandblogging> sorry
[20:06] <juliux> hi boredandblogging
[20:06] <juliux> boredandblogging: do you hear anything form popey, janc oder effi?
[20:06] <juliux> popey: =
[20:07] <leoquant> janc or janC?
[20:07] <juliux> janc
[20:07] <juliux> ähh JanC ;)
[20:18] <juliux> i am sorry but i think we have to cancle the meeting we have no quorum to approv locoteams and nxvl isn´t here for his issue
[20:18] <juliux> as somebody something else, which is urgent?
[20:19] <DoruHush> juliux: it is canceled forever?
[20:19] <juliux> DoruHush: not for ever but for today
[20:19] <DoruHush> or for an other date?
[20:19] <juliux> DoruHush: we will announce the next meeting soon
[20:19] <DoruHush> ok
[20:19] <juliux> i am sorry
[20:20] <elendil> np
[20:20] <manuelciosici> well, see you next time:)
[20:20] <alex3f> see ya
[20:21] <elendil> bye for now - have a good day/night/whatever ;)
[20:21] <GiorgosL[GR]> ok byeby
[20:28] <popey> moo
[20:28] <popey> erk
[20:28] <popey> too late - sorry
[20:29] <DoruHush> I'm still here
[20:29] <DoruHush> hello
[20:29] <juliux> hey popey
[20:30] <juliux> popey: we canceld the meeting, but if you and boredandblogging have time we can do some points;)
[20:30] <popey> email issues, now resolved, didnt realise we had a meeting today
[20:30] <popey> i can be around for the next 30 mins, yes
[20:30] <simosx> can we have a word as to who where missing from the meeting (and it got cancelled)? As in 'from the six council members, only four attended', or something like that.
[20:31] <popey> i was missing simosx and by the look of it so was JanC
[20:31] <juliux> simosx: ?
[20:32] <juliux> simosx: there where only 2/5 of the council so we had no quorum
[20:32] <juliux> popey: is next week bevor the cc meeting working for you? so same time same day next week
[20:32] <current88> by all
[20:32] <popey> yes juliux
[20:33] <juliux> good so we have the next lococouncil next week
[20:34] <juliux> popey: boredandblogging will send out all the mails;)
[20:45] <nxvl> i'm still on time?
[20:45] <nxvl> or i am too late?
[20:46] <Ow1> too late
[20:46] <nxvl> :(
[20:46] <Ow1> al least for loco council
[20:46] <Ow1> :)
[20:46] <Ow1> but you are on time for the next meeting
[20:47] <nxvl> i need to get some thing discussed with the LoCo Council
[20:47] <nxvl> boredandblogging: still here?
[20:47] <nxvl> popey: ?
[20:47] <popey> wassup?
[20:48] <nxvl> popey: i got the times wrong and i think is too late for the meeting?
[20:48] <popey> i did too
[20:48] <nxvl> :()
[20:48] <nxvl> :(
[20:49] <Ow1> well guy, I also wrote an email on the loco-contact maillinglist
[20:49] <Ow1> and I am disapointed by this meeting
[20:50] <Ow1> and how did you prepare this meeting
[20:50] <nxvl> nah, LoCo council rocks
[20:50] <nxvl> is just that i completely forgot about the meeting
[20:50] <Ow1> it may be.
[20:51] <Ow1> but for now the loco council proves me that they don't treat the problems with sufficient seriosity
[20:51] <nxvl> actually they do
[20:51] <Ow1> no hard feelling.
[20:51] <Ow1> it's just my feedback
[20:52] <popey> I'm sorry you feel that way Ow1, it's my fault I wasnt here on time, I apologise
[20:52] <Ow1> I accept your apology
[20:52] <Ow1> and as I said, I don't have bad feeling for any of you guys
[20:52] <persia> Ow1: What problem isn't being treated seriously?  If there's something that's critical, it can often be discussed over email between meetings.
[20:53] <Ow1> the presence problem
[20:53] <juliux> Ow1: what is your actual problem? most of the loco council members are 24/7/365 on irc and our mailbox is open for you allways
[20:53] <Ow1> you get me wrong
[20:53] <juliux> Ow1: and we will have the next meeting next week
[20:54] <juliux> Ow1: same day same time only one week later
[20:54] <Ow1> juliux: OK
[20:54] <juliux> and we hope that we then have a quorum
[20:54] <Ow1> me too
[20:55] <juliux> so cu next week
[20:55]  * juliux goes to bad
[20:57] <nxvl> juliux: is there any ML i can use to discuss my topic?
[20:57] <popey><EMAIL_ADDRESS>[20:57] <nxvl> popey: can i suscribe to it or it's closed?
[20:57] <nxvl> subscribe*
[20:57] <popey> closed
[20:58] <popey> if you mail to it, we will cc you in replies
[20:58] <nxvl> ok
[20:58] <nxvl> that's what i thougt
[21:12] <nxvl> ok, mail sended
[21:12] <nxvl> popey: who needs to approve it?
[21:19] <boredandblogging> nxvl: anyone on the loco-council can approve it, I approved your email
[21:20] <nxvl> \o/
[21:22]  * c00l2sv says hi to everyone


[00:09] <manukapua> cool that seemed to work ok cheers sarnold for the assistance
[00:09] <sarnold> manukapua: don't forget to put back the -meta kernel package if you removed it earlier, to keep getting kernel updates
[00:10] <manukapua> its still there : )
[00:22] <lxle> Anyone know if when 'unattended-upgrades' is set to download the packagelist, does it download an entire packagelist or just the 'allowed' repository parameters you have set, like 'security'
[06:20] <lordievader> Good morning
[11:50] <zioproto> coreycb, rbasak at SWITCH testing our new Xenial/Newton setup we figured out that we are hitting this bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389 This must be fixed before we can move on from Trusty/Mitaka. We need to bug fixed to be able to live-migrate VMs safely, because we evacuate the nova-compute nodes to reprovision them with
[11:50] <zioproto> Xenial/Newton. Do you know about this bug ?
[11:52] <rbasak> I don't know about it, sorry.
[11:52] <rbasak> I'd ask cpaezler but he's out
[11:52] <rbasak> jgrimm: ^
[11:53] <zioproto> rbasak: but you commented on the bug :O !
[11:54] <zioproto> are you Robie Basak (racb) ?
[11:54] <rbasak> zioproto: not with any knowledge, just referring more relevant people.
[11:54] <rbasak> Yes.
[11:54] <zioproto> ah ok :)
[11:54] <zioproto> I all come back here when is daytime in the US :)
[11:57] <coreycb> zioproto, did you see the workaround mentioned?
[11:57] <coreycb> zioproto, i'm just scrolling through the bug coming up to speed
[11:59] <zioproto> coreycb: if you mean  'virsh dommemstat --live --period 0 <VM instance name>' we tried this and did not work
[12:00] <coreycb> zioproto, it looks like turning live_migration_tunnelled off is a work around too
[12:03] <zioproto> coreycb: ok, I found something else to check. We had the default value for live_migration_tunnelled
[12:04] <mdeslaur> zioproto: FYI, there are _untested_ pre-release packages to work around that bug here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
[12:04] <zioproto> now it looks like Mitaka has live_migration_tunnelled default to True and Newton has live_migration_tunnelled default to False
[12:04] <coreycb> thanks mdeslaur
[12:05] <mdeslaur> they haven't had any sort of QA yet, but you're welcome to try them out in a test environment
[12:05] <zioproto> mdeslaur: thanks ! I will try them !
[12:09] <zioproto> mdeslaur: the source server is Trusty, the destination server is Xenial. It is enough to install the qemu package on the Xenial server to test the live migration fix ?
[12:10] <mdeslaur> zioproto: I think so, but I'm not sure, sorry.
[12:11] <cpaelzer> rbasak: here chiluk is the expert on this bug
[12:11]  * cpaelzer is not here
[12:13] <cpaelzer> and I see mdeslaur is also here, perfect
[12:13] <cpaelzer> so I can be away then
[12:13]  * cpaelzer silences his speaker to not get back to the office on a highlight
[12:16] <zioproto> I have a question on live_migration_tunnelled in nova.conf
[12:16] <zioproto> so this is an important setting to be explicit in nova.conf on the controller or on the compute nodes ?
[12:30] <zioproto> mdeslaur: so we installed qemu-system-x86_2.5+dfsg-5ubuntu10.11_amd64.deb and qemu-block-extra_2.5+dfsg-5ubuntu10.11_amd64.deb only. These packages we installed them only on the Xenial target compute-node. We did not touch at all the source Trusty compute node. I can confirm this packages fixed the bug #1647389 for me
[12:31] <mdeslaur> zioproto: oh, great, thanks for testing it
[12:31] <zioproto> my team here is thanking you, because these package repo is not linked on the bug report
[12:32] <zioproto> I guess if the link was there more people had tested the packages, because 12 people are watching the bug
[12:32] <mdeslaur> zioproto: they will be released as security updates once they have been through QA...probably in a couple of weeks
[12:32] <mdeslaur> I'll add a comment to the bug
[12:32] <zioproto> thank you
[15:10] <nacc> cpaelzer: re: LP: #1673714, what is dquilt?
[16:00] <roaksoax> /w/win 8
[16:40] <erick3k> quick question
[16:40] <erick3k> the command route add is permanent
[16:44] <nacc> erick3k: that's not a question, but no
[16:45] <nacc> erick3k: if you reboot, the routes will be gone
[16:53] <erick3k> hehe
[16:55] <erick3k> nacc whats the best way to add them permanent that don't involve puting them in /etc/network/interfaces?
[16:55] <erick3k> and apart from puting them in /etc/rc.local
[16:55] <erick3k> or rc.local best way?
[16:56] <nacc> erick3k: any reason for not using /e/n/i ?
[16:57] <erick3k> Yes, cloud-init will remove the post up / post down commands
[16:57] <erick3k> in interfaces
[16:57] <erick3k> so it has to be somewhere else
[16:58] <nacc> erick3k: that seems like soething to ask cloud-init about, i assume there is either a way to not do that or some config option
[16:59] <erick3k> yes am sure cloud-init has an option, but my current system won't allow me
[16:59] <erick3k> so forget about cloud-init
[16:59] <erick3k> back to first question hehe
[16:59] <nacc> erick3k: will c-i remove /e/n/i.d entries too?
[17:00] <erick3k> well am wrong, and you are kind of right
[17:01] <erick3k> thats where ci puts the config
[17:01] <erick3k> so i guess it doesn't touch interfaces
[17:01] <nacc> there you go :)
[17:01] <erick3k> thats the best place anyway to put them permanent routes?
[17:01] <nacc> erick3k: aiui, but i'm not necessarily an expert on it :)
[17:02] <erick3k> kool ty
[17:02] <nacc> erick3k: np
[17:13] <erick3k> ummm
[17:13] <erick3k> any ideas what can be wrong? looks good to me https://i.imgur.com/dyJhjhD.png
[17:15] <nacc> erick3k: do you have the `route` command? or what is happenig?
[17:15] <erick3k> not sure, i am following this guide http://docs.ovh.ca/en/guides-network-bridging.html
[17:16] <erick3k> but yea route command is there
[17:16] <erick3k> i can use it manually to add the routes and works
[17:16] <nacc> erick3k: oh sorry misread the bottom f it
[17:16] <nacc> erick3k: which line is 14?
[17:17] <erick3k> first post-up command
[17:18] <nacc> erick3k: oh of course
[17:19] <nacc> erick3k: it's an iface option
[17:19] <nacc> erick3k: what are you post-up'ing in that file? :)
[17:19] <erick3k> umm the routes
[17:19] <nacc> erick3k: as in, post "what"'s up state woudl that command run?
[17:19] <nacc> erick3k: routes aren't up
[17:19] <erick3k> it should run route add when the interface goes up
[17:19] <nacc> erick3k: right, *which* interface
[17:19] <nacc> erick3k: syntactically your file makes no sense
[17:19] <erick3k> is on /.d
[17:20] <nacc> erick3k: post-up only makes sense in the context of a interface definition
[17:20] <erick3k> ok so can't put them on .d cuz is gonna be modified by ci
[17:20] <erick3k> so am stuck to rc.local then?
[17:22] <nacc> erick3k: so you want to add a route to a iface that c-i configures?
[17:22] <erick3k> correct
[17:22] <erick3k> ci configures on /e/n/i/.d
[17:23] <erick3k> without having to tell ci to do it because i can't
[17:24] <nacc> i don't understand fully why you can't but ok
[17:24] <nacc> erick3k: you don't control your cloud-config?
[17:24] <nacc> erick3k: it seems like you can define routes vai systemd.network as well
[17:25] <erick3k> yes and no, is limited. That would be the obvious solution but perhaps why am here looking for another solution
[17:25] <erick3k> rc.local is gonna work, ive used before but i don't think is the  best way
[17:26] <erick3k> nacc i would have to somehow modify rhev completly, templates etc to be able to add routes on cloud-init launch
[17:26] <erick3k> that is beyond me
[17:26] <erick3k> thats why
[17:26] <nacc> erick3k: huh?
[17:26] <erick3k> rhev / orvirt
[17:26] <nacc> erick3k: you aren't able to pass cloud-config to your instances?
[17:26] <erick3k> yes
[17:26] <erick3k> but limited config
[17:27] <erick3k> so ovirt which is the system i use
[17:27] <nacc> erick3k: hrm, dunno
[17:27] <erick3k> doesn't have an option to pass routes throught cloud-init
[17:27] <nacc> erick3k: but ok
[17:27] <erick3k> so i simple can't use cloud init to pass routes
[17:27] <erick3k> very simple
[17:28] <erick3k> so i want permanent routes on the O.S
[17:28] <erick3k> that has nothing to do with cloud-init
[17:29] <nacc> erick3k: but you can write arbitrary files? i'm super confused :)
[17:34] <erick3k> nacc sorry got dced
[17:35] <erick3k> but nvm i'll just stick to adding routes with rc.local
[17:35] <nacc> erick3k: yeah, i think that's easiest for wht you've described
[18:27] <teward> has anyone had an issue where an upgrade on Xenial of mysql-server-5.7 would totally lag out and just consume all the memory and swap?
[18:27] <teward> because that happened on my mail server :/
[18:44] <erick3k> hi
[18:44] <erick3k> i see in ubuntu 16.04 /etc/init/rc-sysinit.conf was removed
[18:44] <erick3k> what is it now?
[18:46] <sarnold> I can't figure out what that thing's supposed to do..
[18:47] <erick3k> what thing
[18:47] <erick3k> ?
[18:47] <sarnold> erick3k: systemd aims to run multi-user.target, and runs whatever is supposed to be run to make that happen
[18:47] <sarnold> erick3k: if you want to change the systemd target, this might help https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Targets.html#sect-Managing_Services_with_systemd-Targets-Change_Default
[18:48] <erick3k> ummm
[18:48] <erick3k> i just wanted to change start on (filesystem and static-network-up) or failsafe-boot
[18:48] <erick3k> but is no longer in ubuntu 16
[18:49] <erick3k> 14 the file is there
[18:49] <sarnold> what's the task that you're actually trying to solve?
[18:51] <erick3k> my problems is network timeouts on boot
[18:52] <erick3k> so i want to disable network to start on boot
[18:52] <erick3k> or bypass all timeouts or waits for network
[18:52] <erick3k> in centos i put ONBOOT=no
[18:52] <erick3k> ubuntu 14 change start on (filesystem)
[18:53] <erick3k> now on 16 i don't know
[18:53] <erick3k> doesn't have same options as 14
[18:54] <erick3k> the root of the problem is that i don't use dhcp for network, instead i use static but is injected by cloud-init
[18:54] <erick3k> and is done after the network is started
[18:54] <erick3k> so it will timeout
[18:56] <erick3k> sarnold this worked perfectly on ubuntu 14
[18:56] <erick3k> http://askubuntu.com/questions/185515/disable-network-configuration-services-during-boot-time
[18:56] <erick3k> i want the same for ubuntu 16
[18:56] <erick3k> simple
[18:57] <Logos01> ... I'm assuming you mean 14.04 and 16.04 respectively
[18:57] <erick3k> correct
[18:57] <Logos01> ( Y.ear Y.ear . M.onth M.onth ) -- sorry, that's a pet peeve of mine
[18:57] <erick3k> but those files are not present on ubuntu 16.04 only in 14.04
[18:58] <Logos01> Right because it operates differently
[18:58] <Logos01> You're seeing the timeout/delay?
[18:58] <erick3k> yes
[18:58] <erick3k> very long
[18:58] <Logos01> Oh wait ... "instead I use static but is injected by cloud-init"
[18:58] <Logos01> This is in what cloud provider?
[18:58] <erick3k> yes
[18:59] <rharper> erick3k: please join #cloud-init and we can help debug from there
[18:59] <erick3k> oh trust me
[18:59] <erick3k> already tried
[18:59] <erick3k> only one that can help is smores and he busy all the time
[19:00] <rharper> I work on cloud-init as well, have you filed a bug with the details ?
[19:00] <erick3k> i know cloud-init has a timeout on cloud-init-nonet.conf that i already removed
[19:00] <erick3k> am not looking for cloud-init timeouts but the looking for network in ubuntu 16 while booting
[19:00] <Logos01> erick3k: Have you looked at /etc/network/interfaces yet?
[19:01] <erick3k> yep, no timeout
[19:01] <Logos01> No there wouldn't be there; that's not even a concept.
[19:01] <rharper> in general, the 'networking' service in 16.04 will look at the eni and for each iface thats marked 'auto'; it will wait for all of those to become up
[19:01] <Logos01> Care to share your /etc/network/interfaces ?
[19:02] <rharper> if one or more of those marked auto does not come up, then the networking service itself blocks;
[19:02] <Logos01> Yeah -- I was going to suggest changing the device from "auto" to "manual" in the config and then let cloud-init handle initializing it
[19:02] <Logos01> It's not so much that it *blocks*
[19:02] <Logos01> But that you never pass the network target and so never reach the multi-user target
[19:02] <rharper> but the service itself does block
[19:02] <rharper> that's by design
[19:02] <erick3k> lord i just want the corresponding files /etc/init/failsafe.conf and /etc/init/rc-sysinit.conf but for ubuntu 16.04 that are no longer present
[19:02] <Logos01> rharper: I'm saying this in systemd terminology
[19:02] <rharper> you told it, bring all of these interfaces up
[19:02] <rharper> I mean, it's a oneshot service, calling ifup and friends
[19:03] <rharper> so, is it systemd is it the unit script?
[19:03] <Logos01> erick3k: The concept doesn't exist anymore; there is no corresponding files.
[19:03] <erick3k> right
[19:03] <rharper> doesn't really matter; the effect is to block until all interfaces in eni marked auto are up
[19:03] <erick3k> so i want to know where are the waiting for dhcp timeouts on boot
[19:03] <Logos01> erick3k: The thing that those files were doing, that you needed to tweak -- it no longer exists.
[19:03] <Logos01> You have a different problem.
[19:04] <erick3k> logos01 i understand they no longer exist perhabs why am asking for a 16.04 solution
[19:04] <Logos01> rharper: Well if you speak it in systemd nomenclature it helps you to troubleshoot/diagnose what/where is going on.
[19:04] <rharper> it does an ifquery --allow-auto to list the interfaces from eni which are marked auto; until ifup on each of those interfaces returns and they're up it blocks (for some fixed time)
[19:04] <Logos01> erick3k: Right. Are the interfaces marked auto or manual in /etc/network/interfaces ?
[19:05] <erick3k> logos01 they will be auto after cloud-init injects it
[19:06] <erick3k> now say i seal the vm before using cloud-init
[19:06] <Logos01> erick3k: Right but they're *NOT* auto when the VM is booting.
[19:06] <erick3k> what should be on interfaces to avoid any timeouts
[19:06] <erick3k> correct
[19:06] <erick3k> so what should i put there
[19:06] <erick3k> to avoid them timeouts
[19:06] <Logos01> erick3k: Can we see your /etc/network/interfaces file?
[19:07] <erick3k> auto lo
[19:07] <erick3k> iface lo inet loopback
[19:07] <erick3k> source /etc/network/interfaces.d/*.cfg
[19:07] <erick3k> thats it
[19:07] <Logos01> Okay what's in the /etc/network/interfaces.d/ directory?
[19:07] <rharper> so cloud-init will write a 'dhcp on "first" interface' on instances which do not provide a network configuration;  if do not want cloud-init to attempt to configure networking via fallback, you can tell cloud-init to disable network configuration
[19:07] <erick3k> https://i.imgur.com/EJDmklx.png
[19:07] <rharper> there's a 50-cloud-init eni file which will attemtp to dhcp on one of the interfaces
[19:08] <erick3k> yes i can delete that 50-cloud-init.cfg before sealing the vm
[19:08] <erick3k> thats not a problem
[19:08] <Logos01> erick3k: lpaste the output of:  `grep -H '' /etc/network/interfaces.d/*.cfg`
[19:08] <erick3k> the only file that is on inderfaces.d will be deleted
[19:09] <erick3k> before sealing the vm logos01
[19:09] <erick3k> so makes no sense showing you that file
[19:09] <Logos01> Well this is where your problem is ... because the machine is attempting to dhcp up -- it has to, because that's how cloud-init *works*
[19:09] <erick3k> right
[19:09] <Logos01> Even if you get a static lease on whatever the following interface/address is, that's different.
[19:10] <rharper> no, you need to tell cloud-init via config that you don't want it to attempt ot configure networking;  you can write out "network: {config: disabled}" into a /etc/cloud/cloud.cfg.d/network-disable.cfg
[19:10] <Logos01> You're getting blocked because you're not *getting* dhcp addressing the machine is looking for.
[19:10] <erick3k> so on ubuntu 14 i fixed by using those commands or mods i showed you on ask ubuntu
[19:10] <rharper> that prevents cloud-init from attempt to configure networking for you
[19:10] <Logos01> erick3k: That didn't actually fix the problem in question. 14.04 used a *completely different* networking model than 16.04
[19:10] <Logos01> All it did was make the problem non-blocking to boot.
[19:10] <Logos01> You cannot do that in 16.04.  It cannot be done.
[19:11] <Logos01> You have to either resolve the problem or have a successful startup of the networking service that doesn't depend on the problem's being solved.
[19:11] <erick3k> ok so i will get 15 minutes time out while booting no matter what i do?
[19:11] <Logos01> Did I just say that?
[19:11] <Logos01> (No.)
[19:11] <erick3k> well the solution would be not to get network up until cloud-init injects the static ip
[19:12] <erick3k> but that is not how is happening
[19:12] <rharper> how are you injecting networking in cloud-init ?
[19:12] <erick3k> config drive / nocloud
[19:12] <rharper> then you have control over what gets rendered in the 50-cloud-init.cfg file
[19:13] <erick3k> and it works
[19:13] <rharper> in the network config in the nocloud seed, make sure you don't attempt to dhcp on non-existent interfaces
[19:13] <erick3k> https://i.imgur.com/PXBt5N2.png
[19:13] <erick3k> perfectly
[19:13] <erick3k> only after 15 minutes of timeouts
[19:14] <rharper> so I suspect that your first nic isn't getting the name 'eth0'
[19:14] <rharper> 16.04 uses persistent nic naming, so it'll be like ens3 or ens1p1
[19:14] <erick3k> yea i did the grub biosdevicename thingy
[19:15] <erick3k> na, it must be eth0
[19:15] <rharper> that looks fine, if eth0 is present, then ifup on eth0 should be just fine;
[19:15] <erick3k> right but when i seal the vm
[19:15] <erick3k> eth0 will not exist until cloud-init injects it
[19:15] <erick3k> so ubuntu will timeout trying to get it with dhcp
[19:16] <rharper> so you must not be embedded the datasource into /var/lib/cloud/seed/nocloud-net/
[19:16] <erick3k> ummm
[19:16] <erick3k> let me try
[19:16] <rharper> when you boot it soemwhere else, it'll have a new instance id, in which case the previous config may not apply
[19:16] <rharper> in there you'll also set a meta-data with an instance-id: <unique string>
[19:17] <erick3k> yes that i delete before sealing
[19:17] <erick3k> correct?
[19:17] <erick3k>  /var/lib/cloud/instances
[19:18] <rharper> if this is a template then, yes;
[19:22] <erick3k> okay no timeout
[19:23] <erick3k> that worked
[19:23] <erick3k> i think i wasn't clearing /var/lib/cloud/instances and caused the problem
[19:23] <rharper> you can also write a network-config file for the nocloud-net seed like so
[19:24] <rharper> http://paste.ubuntu.com/24335893/
[19:25] <rharper> format is documented here: http://curtin.readthedocs.io/en/latest/topics/networking.html  ;   I've an PR to get that published under the cloud-init docs
[20:18] <ThiagoCMC> Guys, I'm trying to launch an Instance on Ocata / Ubuntu 16.04, with DPDK and hugepages, the following error is appearing on nova-compute.log:
[20:18] <ThiagoCMC> can't open backing store /dev/hugepages-1048576/libvirt/qemu for guest RAM: Permission denied
[20:18] <ThiagoCMC> Any tips?
[20:18] <ThiagoCMC> Might be related to https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1524737 ?
[20:21] <ThiagoCMC> I'm also seeing "apparmor="DENIED"" at my syslog...  =/
[20:25] <sarnold> ThiagoCMC: ubuntu-bug libvirt, please, and make sure to include those DENIED lines
[20:25] <ThiagoCMC> Damn... ok!
[20:25] <ThiagoCMC> =P
[20:27] <ThiagoCMC> "ubuntu-bug libvirt0", right?
[20:27] <ThiagoCMC> never mind, sending
[20:28] <rharper> https://help.ubuntu.com/lts/serverguide/DPDK.html
[20:28] <rharper> may be of help as well
[20:29] <sarnold> rharper: nice, thanks
[20:29] <rharper> all thanks go to cpaelzer
[20:30] <sarnold> cpaelzer, thanks for the nice https://help.ubuntu.com/lts/serverguide/DPDK.html guide it looks like good reading :)
[20:33] <ThiagoCMC> Reported: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1524737
[20:33] <ThiagoCMC> Oops
[20:33] <ThiagoCMC> Damn clipboard are...
[20:33] <ThiagoCMC> https://bugs.launchpad.net/cloud-archive/+bug/1680956
[20:33] <ThiagoCMC> I can easily use Ubuntu with DPDK for my VMs...
[20:34] <ThiagoCMC> Problem is when with OpenStack... Plain KVM is fine.
[20:35] <nacc> ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it?
[20:36] <ThiagoCMC> It is: libvirt-bin 2.5.0-3ubuntu5~cloud0
[20:36] <nacc> ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it?
[20:36] <nacc> bah
[20:36] <nacc> ThiagoCMC: do you know ifthe libvirt in openstack has the fix to LP: #1524737 in it?
[20:36] <nacc> i'm also a bit confused why that bug was closed by 1.2.21-2ubuntu3
[20:36] <ThiagoCMC> Hmmm.. I don't...
[20:37] <ThiagoCMC> If it was fixed a long time ago...
[20:37] <nacc> ThiagoCMC: sorry bad keystroke earlier
[20:37] <ThiagoCMC> np
[20:37] <nacc> ah it was fixed in 1.2.21-2ubuntu2 and lp is being weird
[20:37] <ThiagoCMC> maybe re-introduced?
[20:38] <nacc> ThiagoCMC: about to eat lunch but i can check on it
[20:38] <ThiagoCMC> Enjoy it!   :-D
[21:15] <erick3k> omg help
[21:16] <erick3k> rharper you still on?
[21:16] <tsimonq2> !help | erick3k
[21:16] <erick3k> the machine now gets stuck here https://i.imgur.com/DVpf0RX.png
[21:16] <erick3k> why is raid loading am using no raid thing
[21:29] <nacc> erick3k: that's mdadm reloading
[21:29] <nacc> erick3k: *loading
[21:29] <nacc> erick3k: it has to know what raid levels are allowed so that you can use raid if you want or not
[21:29] <nacc> erick3k: i'm 99% sure that's not what'
[21:29] <nacc> *that's not what's hanging
[21:31] <nacc> ThiagoCMC: back, sorry for the delay
[21:32] <erick3k> nacc ok checking
[21:33] <ThiagoCMC> nacc, oh, that's totally ok!   ^_^
[21:34] <nacc> ThiagoCMC: ok, so 2.5.0-3ubuntu5, in the source, does have
[21:34] <nacc>   # for access to hugepages
[21:34] <nacc>   owner "/run/hugepages/kvm/libvirt/qemu/**" rw,
[21:34] <nacc>   owner "/dev/hugepages/libvirt/qemu/**" rw,
[21:35] <ThiagoCMC> Hmm...
[21:35] <ThiagoCMC> =/
[21:36] <nacc> ThiagoCMC: should be abel to confirm by looking at /etc/apparmor.d/abstractions/libvirt-qemu on the host
[21:36] <ThiagoCMC> Checking...
[21:37] <nacc> ThiagoCMC: oh!
[21:37] <nacc> ThiagoCMC: the path changed!
[21:37] <nacc> ThiagoCMC: why is it /dev/hugepages-1048576 ?
[21:37] <nacc> ThiagoCMC: can you pastebin `ls -ahl /dev/hugepages*`?
[21:38] <ThiagoCMC> Yes, /etc/apparmor.d/abstractions/libvirt-qemu have those two lines.
[21:40] <ThiagoCMC> ls -ahl output: https://paste.ubuntu.com/24336518/
[21:40] <nacc> ThiagoCMC: is this the system where you were using 1g hugepages?
[21:41] <ThiagoCMC> yep
[21:42] <ThiagoCMC> I can launch an Instance on top of OVS+DPKD (OVN topology), but, when I try the hugepages on OpenStack's flavor, it doesn't boot because of this apparmor stuff
[21:42] <nacc> sarnold: being completely dumb about apparmor, can you look at LP: #1689056 ? I am unable to put my comment in lp, due to timeouts righ tnow, but: http://paste.ubuntu.com/24336524/
[21:42] <nacc> bah
[21:42] <nacc> LP: #1680956
[21:43] <nacc> sarnold: also, why does `man apparmor` on 17.04 refer to upstart? :)
[21:43] <nacc> "Ubuntu systems use upstart(8) instead of a traditional SysV init system."
[21:43] <nacc> ugh
[21:45] <ThiagoCMC> Nevertheless, something else is going on here... I mean, this is for sure a problem (LP 1680956). And, when I try it without hugepages, the VM boots up but, it can't ping OVN L3 Router... But, this is a different problem entirely.
[21:45] <ThiagoCMC> Oh this ubottu... lol
[21:45] <ThiagoCMC> =P
[21:45] <nacc> sarnold: and one last thing for the security time, the manpage refers to : http://wiki.apparmor.net/index.php/Distro_ubuntu
[21:46] <nacc> which, um, is as currnet as 11.04 :)
[21:54] <erick3k> nacc what could it be?
[21:54] <erick3k> i can't find out why is getting stuck
[21:55] <erick3k> nacc now booted, where can i look for that ugly timeout
[21:55] <erick3k> ?
[21:55] <nacc> erick3k: i'd look in syslog, messages, dmesg, etc
[21:55] <erick3k> k
[21:57] <erick3k> nacc is the stupid network again
[21:57] <erick3k> i can reproduce by using cloud-init network as dhcp
[21:57] <nacc> erick3k: ah
[21:57] <erick3k> i use static btw
[21:57] <nacc> erick3k: do you not have network on first boot or something? or using dhcp but not really?
[21:58] <erick3k> this is the options on the template hold on
[21:58] <sarnold> nacc: wow, nice bugs all around :)
[21:58] <erick3k> https://i.imgur.com/IG9URrT.png
[21:58] <nacc> sarnold: my guess on profile seems ok, at least :) but will probably need a fix and sru, cpaelzer
[21:58] <erick3k> should i remove the start on boot?
[21:59] <nacc> erick3k: i have no idea how ovirt works so i don't know
[21:59] <erick3k> or untick network
[21:59] <erick3k> nice back to square 1 again :(
[21:59] <erick3k> thats why
[21:59] <erick3k> before
[21:59] <nacc> erick3k: i would guess you could try those options, but i wonder if it will just fail to boot at all
[21:59] <erick3k> i wanted to attack the stupid timeouts
[22:00] <erick3k> not cloudinit or ovirt who cares
[22:00] <erick3k> is stupid ubuntu timing out looking for dhcp
[22:00] <erick3k> all other O.S work great, including 14.04
[22:01] <erick3k> 5 days trying to fix the stupid timeout, bout to give up on ubuntu
[22:01] <erick3k> my customers can stick to 14.04 lol
[22:04] <nacc> this seems relevant: https://review.openstack.org/#/c/416664/
[22:04] <nacc> https://bugs.launchpad.net/tripleo/+bug/1653812
[22:04] <nacc> looks like ONBOOT is the issue, but i'm not sure if you actually need it for your case
[22:05] <erick3k> nacc on centos 7 yes i put ONBOOT=no and thats it issue fixed
[22:05] <erick3k> is there an option like that in ubuntu?
[22:05] <nacc> erick3k: where do you put that?
[22:06] <erick3k> centos /etc/sysconfig/network-scripts/ifcfg-eth0
[22:07] <erick3k> is there a way to completly block the network from starting on boot and then just rc.local a command to start it?
[22:07] <erick3k> am desperate
[22:07] <erick3k> anything works i dont care
[22:08] <nacc> erick3k: ip=off maybe
[22:08] <nacc> erick3k: on the kernel commandline
[22:08] <nacc> but i don't understand, if you're cloud based, you depend on network in order to boot, i'd assume
[22:08] <erick3k> not really since am not using dhcp
[22:08] <erick3k> am using static network
[22:09] <nacc> that doesn't matter
[22:09] <erick3k> i put the ip's
[22:09] <nacc> you still depend on network
[22:09] <nacc> it sounds like you've got a configuration issue
[22:09] <nacc> somewhere, id on't understand your deployment
[22:09] <nacc> but it should not be doing dhcp, i think is your root point
[22:09] <erick3k> right
[22:09] <nacc> but you aren't telling it (afaict) that it's got static networking
[22:09] <nacc> erick3k: you can of course pass networking information to guests on the kernel command-line, but i don't understand when you're having this issue
[22:10] <erick3k> so i got 5 oses working but ubuntu 16.04 am sure the system / deployment is fine
[22:10] <nacc> first boot with cloud-init?
[22:10] <erick3k> i just want ubuntu to stop waiting for dhcp
[22:10] <erick3k> where is the dhcp wait time set in ubuntu 16?
[22:10] <nacc> probably /etc/dhcp/dhclient.conf
[22:10] <nacc> yeah, it's set to 300 there
[22:11] <nacc> but again, it only would do that if it is configured to dhcp at all
[22:11] <nacc> so don't configure your images to dhcp
[22:11] <erick3k> ok gonna try that
[22:11] <nacc> i don't understand why you think you don't have a configuration issue
[22:11] <erick3k> yes am not sure why is even picking dhcp
[22:11] <nacc> i don't carea bout your other images
[22:11] <erick3k> i don't have no dhcp nowhere
[22:11] <nacc> yes, i understand -- so how are your other instances getting network configuration?
[22:11] <nacc> erick3k: you boot an instance and configure it?
[22:11] <erick3k> all get them throught cloud-init
[22:11] <nacc> erick3k: how do you do that?
[22:12] <nacc> *how*
[22:12] <nacc> they dont' have network at boot
[22:12] <nacc> since you're not using dhcp
[22:12] <nacc> i think you or I am missing something obvious
[22:12] <erick3k> no, you clean the vm, sealed, boot it with cloud-init (ovirt plugs a floppy with config drive / nocloud) and boots while picking up the info injected throught the floppy
[22:12] <nacc> ah you are using a config drive
[22:12] <nacc> ok
[22:13] <erick3k> oyes
[22:13] <nacc> i don't know what 'sealed' is
[22:13] <nacc> yeah, so if you don't need network to boot, don't set it to onboot (that gui you showed earlier)
[22:13] <nacc> or send ip=off, i guess
[22:13] <erick3k> just get it ready for customer, delete /var/lib/cloud/instances, history, interfaces etc
[22:14] <erick3k> yes, i tried all options on that gui, nothing works
[22:14] <erick3k> where do i add that ip=off
[22:15] <erick3k> GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
[22:15] <erick3k> there nacc?
[22:15] <nacc> yeah, i think so
[22:15] <nacc> erick3k: but that will disable networking period, possibly, that's what i'm not sure about
[22:15] <nacc> erick3k: hence, test it :)
[22:16] <erick3k> by disable you mean you can't even start it with manual command after it boots?
[22:17] <nacc> erick3k: i'm not sure, i can't remember if that twiddles anythin gmore than just not doing any network configuration at boot
[22:17] <erick3k> that would work
[22:17] <erick3k> trying
[22:18] <sarnold> kind of strange that the only mention of 'network-interface' in the docs is on the nocloud datasource :( http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html?highlight=network-interfaces
[22:19] <nacc> sarnold: right, but earlier erick3k said they didn't have control over cloud-init
[22:19] <nacc> sarnold: but agreed, it's strange
[22:20] <sarnold> nacc: I'm surprised no one's needed to integrate cloud-init with an IPAM service before to make this easier..
[22:20] <jgrimm> sarnold, nacc: more docs on the way fwiw -> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+ref/network-config-doc
[22:21] <erick3k> ok with ip=off booted now let me add an ip see what happens
[22:21] <nacc> jgrimm: thanks
[22:21]  * jgrimm EOWs
[22:23] <sarnold> jgrimm-away: thanks, have a good weekend
[22:30]  * jgrimm-away waves
[22:31] <erick3k> nacc ip=off just completly remove network
[22:31] <erick3k> cloud-init doesn't even add an interface
[22:34] <erick3k> nacc, is there a default that after the 300 seconds timeout on dhcp, ubuntu will retry?
[22:34] <erick3k> i see on /etc/dhcp/dhclient.conf is commented out #retry 60; so  by default ubuntu does not retry?
[22:38] <nacc> erick3k: did you rebuild your initrd after changing that file?
[22:39] <erick3k> if you mean update-grub yes
[22:39] <nacc> no
[22:39] <nacc> that updates grub
[22:39] <nacc> has nothing to do with your initrd
[22:39] <nacc> i'm fairly sure you need to update the initrd on the image in order for that file to affect boot
[22:40] <erick3k> yes i know :)
[22:40] <erick3k> eitherway ip=off is a nono
[22:40] <erick3k> is like removing the nic card physically
[22:45] <erick3k> nacc sorry you mean dhclient?
[22:45] <erick3k> file
[22:45] <nacc> erick3k: yeah /etc/dhcp/dhclient.conf edited without an initrd update doesn't do anything afaict
[22:45] <erick3k> ummm
[22:49] <erick3k> k doing it
[22:51] <erick3k> nacc update-initramfs -?
[22:51] <erick3k> -u?
[22:52] <nacc> erick3k: yeah, maybe with -k <version> or -k all
[22:54] <sarnold> if you're editing the image and you just don't want networking, could you use systemctl disaable networking or something similar?
[22:55] <nacc> sarnold: afaict, they do want networking, just not hte dhcp on boot
[22:56] <nacc> sarnold: and i still don't understand how this works on other OSes or if this is a systemd change or what
[22:56] <nacc> as i would think most would be attempting to dhcp on all interfaces by default, if not told otherwise
[22:56] <erick3k> at this point
[22:56] <erick3k> am not even sure is a dhcp problem
[22:57] <erick3k> i mean a machine its been stuck for 1 hour
[22:57] <erick3k> tried that nothing
[22:57] <erick3k> same
[22:58] <erick3k> stuck https://i.imgur.com/UDKYAHZ.png
[22:58] <erick3k> why is raid showing any idea? am not using any raid device
[22:58] <nacc> erick3k: again, i already explained that to you
[22:58] <sarnold> you could probably blacklist the modules if you don't want their startup routines firing
[22:58] <nacc> erick3k: mdadm loads and determines what raid levels are supported
[22:59] <nacc> iirc, at that poitn, it's trying to mount your root fs
[22:59] <nacc> (also based upon my own dmesg)
[23:00] <erick3k> the only difference
[23:00] <erick3k> between me firing the vm manually and with my script (they get stuck) is that the disk size is changed
[23:00] <erick3k> could that make ubuntu not boot?
[23:01] <erick3k> or get stuck there
[23:02] <erick3k> i am sorry guys, maybe has nothing to do with the network
[23:02] <nacc> you're changing the disk size under a fs?
[23:03] <erick3k> i increased the disk size before turning on the machine and reproduced the error :(
[23:03] <erick3k> yes, virtio
[23:03] <nacc> well, at least you disparaged ubuntu in the process! :)
[23:03]  * nacc goes back to other work
[23:03] <erick3k> lol
[23:04] <erick3k> why, isnt it suppose to run growpart and just expand?
[23:04] <erick3k> like the other cloud images i have working?
[23:05] <erick3k> nvm me
[23:05] <erick3k> it booted and did resize the disk https://i.imgur.com/TINxMPD.png
[23:11] <erick3k> i don't know guys i give up for now, maybe one will boot tomorrow and will collect some more info. Thank you nacc and all for your help and time.
[23:13] <nacc> erick3k: gl!


[05:18] <poningru> Mez: ping
[05:19] <Mez> poningru, pong
[05:19] <poningru> Mez: marting meredith?
[05:19] <poningru> err
[05:19] <poningru> -g
[05:19] <poningru> thunderbird probs?
[05:21] <Mez> yup :d
[05:21] <poningru> will you still be around in half an hour
[05:22] <poningru> cause I can help around that time
[05:22] <Mez> #thunderbird ?


[18:14] <knkski[m]> are there any examples of kubernetes charms that talk to mysql that aren't reactive? i.e which use the new operator framework?
[23:36] <utanner> hello