Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 07EC01021F for ; Sun, 21 Jul 2013 16:16:23 +0000 (UTC) Received: (qmail 58410 invoked by uid 500); 21 Jul 2013 16:16:21 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 58342 invoked by uid 500); 21 Jul 2013 16:16:17 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 58327 invoked by uid 99); 21 Jul 2013 16:16:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jul 2013 16:16:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [209.85.220.176] (HELO mail-vc0-f176.google.com) (209.85.220.176) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Jul 2013 16:16:11 +0000 Received: by mail-vc0-f176.google.com with SMTP id ha12so4223198vcb.7 for ; Sun, 21 Jul 2013 09:15:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fE0n4pd2FqlhxLzD1ZfIAHgiS242J0YRjbmPEtVZY3s=; b=Bp+fUhzis65RdP9Uvb8PTv8mjZsOLFfjt9XzYr15BsLQCz9GiiDs7Ouax3c0bJXs23 Qgq1QaAlo25p0d5IxypAYRu1UOh1drHdc8rAtUfq0z4CcViQv13sBgBRjoyGx837unFi XuFXotDM8w7/nnVGLYV1tMBtwPmFkTvYQUxKeDM8bGDuMghlp2uFiF0iyr8msr621lr+ /W9xRGOGPw44bDwrfvFC7lhTxAtmnh0xJa+r2QhjHGnayQ4YkN2PFIeaCnRcUAnEv0eO g0GnKPtCLmh9RCGeDgPe6DUO8k/nWaKxpBRjslBLbRCaex/UqpzzyNxG/p2bljBHaAYb X5rQ== MIME-Version: 1.0 X-Received: by 10.52.0.52 with SMTP id 20mr6822818vdb.22.1374423330163; Sun, 21 Jul 2013 09:15:30 -0700 (PDT) Received: by 10.58.218.33 with HTTP; Sun, 21 Jul 2013 09:15:30 -0700 (PDT) X-Originating-IP: [24.6.135.247] In-Reply-To: References: Date: Sun, 21 Jul 2013 09:15:30 -0700 Message-ID: Subject: Re: Regarding the BLOCKER bug Cloudstack-3589 VM created from VPC network is not getting IP From: Sheng Yang To: "" Cc: "dhoogland@schubergphilis.com" , Alena Prokharchyk , Abhinandan Prateek Content-Type: multipart/alternative; boundary=047d7bacbce85d9e1304e207de47 X-Gm-Message-State: ALoCoQlmzzHxS5H6YLh6TPqXEg+CxFHKRJAWYCFkZ5LBhfCRB82FSrRf47Qk8GePAHeQRCWT+UB9 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bacbce85d9e1304e207de47 Content-Type: text/plain; charset=ISO-8859-1 In fact DnsMasqConfigurator has other issues since it would complete override the whole configuration file modified by bash scripts in the VR. So Bharat is working on that and should send out patch soon, using bash scripts on the dnsmasq.conf instead. Also that's our preferred approach to modify dnsmasq.conf, so I think we can fix the network domain issue after Bharat's patch is checked in. I am sure at least you need a parameter to indicate VPC router. For now, I think the first priority is unblock regression test and vpc function. --Sheng On Sun, Jul 21, 2013 at 9:07 AM, Daan Hoogland wrote: > So if I understand your mail correctly, a VpcDnsMasqConfigurator should be > created to be used in configDnsMasq in VpcVirtualApplienceManagerImpl, > instead of the one used now? > > > On Sun, Jul 21, 2013 at 6:01 PM, Sheng Yang wrote: > > > Hi Daan, > > > > We're talking about vpc router. Your patch affect the guest vm because > > guest VM cannot get ip address from VPC router(DHCP request fail). > > > > The VPC indeed using a different dnsmasq.conf. See > > /etc/vpcdnsmasq.conf(which is a template of VPC used dnsmasq). > > > > You're using DnsMasqConfigurator, which is only used for normal VR before > > your patch. It would generated dnsmasq.conf contained: > > > > > > except-interface=eth1 > > except-interface=eth2 > > except-interface=lo > > > > > > However, these lines by no chance can work in a VPC router, which is > > introduced by your commit. Because for VPC router, eth2 is the first > guest > > nic, it cannot be excepted from listening ports, otherwise any guest vm's > > dhcp request in the first subnet would fail to get IP address through > DHCP. > > > > --Sheng > > > > > > On Sun, Jul 21, 2013 at 3:49 AM, Daan Hoogland > >wrote: > > > > > H Sheng et al, > > > > > > I have no overview of what effect my patch has on guest vm's. It is > > > supposed to only generate a dnsmasq.conf for vpc-router-vm's. not > > > guestnetwork-vm's. I am happy to look at it, but have no overview of > the > > > issue yet. Should a sepperate dnsmasq.conf instance be created for vpc > > > routers to deal with the different nics? > > > > > > > > > On Sat, Jul 20, 2013 at 3:32 AM, Sheng Yang wrote: > > > > > > > Daan, I've checked the code, the issue is, original code Bharat > > > > wrote(generated dnsmasq.conf) cannot deal with VPC. e.g. the VPC > router > > > > wouldn't listen on eth0 and eth1, but non-vpc router wouldn't listen > on > > > > eth1 and eth2. Also, some detail configurations of VPC are written > into > > > > /etc/dnsmasq.d/cloud.conf, rather than dnsmasq.conf, because it need > to > > > > deal with multiple nics with different range. > > > > > > > > So using non-vpc's configuration just break whole VPC function. No > > chance > > > > it can work because eth2(which is internal network interface in VPC) > is > > > > excluded from listening interface. > > > > > > > > We need to deal with it ASAP because it's blocking the regression > test. > > > In > > > > fact I didn't see much solution for now except reverting it since the > > > > dnsmasq config command didn't support VPC anyway. > > > > > > > > BTW, I don't agree that we need dnsmasq configuration file generated > by > > > > cloudstack, since it's possible that the scripts in the VR would > modify > > > the > > > > file as well(e.g. in cloud-early-setup), then the modification would > be > > > > overrided by whole new file generated by management server(which > > happened > > > > in this case). We have to gather them in one place. I've talked with > > > Bharat > > > > and he would provide a patch soon to revert the DnsMasqConfigurator, > > and > > > > use bash scripts to do the necessary substitute instead. I think any > > > > potential change to dnsmasq config command need to wait for it. > > > > > > > > --Sheng > > > > > > > > > > > > On Fri, Jul 19, 2013 at 5:54 PM, Sheng Yang > wrote: > > > > > > > > > Daan, > > > > > > > > > > Bharat thinks your fix caused a block bug > > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-3589? Could you > > check > > > > it? > > > > > > > > > > --Sheng > > > > > > > > > > On Thu, Jul 18, 2013 at 9:52 AM, Bharat Kumar < > > bharat.kumar@citrix.com > > > > >wrote: > > > > > > > > > >> Hi Dann, > > > > >> > > > > >> The bug fix > > > > >> > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=b903262df5e2ff5d174859ce28abae75c4689f0cis > > > > >> causing an null value in dnsmasq.config file while creating VPC > > > network > > > > >> (bug-id Cloudstack-3589 ). > > > > >> > > > > >> Can you please take a look at this. > > > > >> > > > > >> Regards, > > > > >> Bharat. > > > > > > > > > > > > > > > > > > > > > > > > > --047d7bacbce85d9e1304e207de47--