Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAGQtxvYv1SPV7wV=L79PdNjsZ++AkMAWvpU9W-vg0mDjzaOETQ@mail.gmail.com>
References: 
 <CA+2rt41-po=1YO4WvfzO+R9Y78kSF0Lc-iJDz4jXG6oMRkUc7A@mail.gmail.com>
	<CA+2rt42iWVZHP_NsxntjBA9n=eJUgWkKM45Guu7YMF54MuW-bA@mail.gmail.com>
	<CAGQtxva1p218v1nfH2e35-MkVVAisJX5ck-8U1utMjxF6di=aA@mail.gmail.com>
	<CA+2rt40dGyBYNC9FEx0Zav=X_sd6sBb854pq8kZ4RtSAFM4siA@mail.gmail.com>
	<CAGQtxvb+XuF3DdJMQ5CmBVrB8JOmTsmkYK819nk+xa6HaWb-Bw@mail.gmail.com>
	<CA+2rt40XQGFukt1OGBc1YVEo24Kn8Xc5ew8atqPRWgKKTUbX5A@mail.gmail.com>
	<CAGQtxvYv1SPV7wV=L79PdNjsZ++AkMAWvpU9W-vg0mDjzaOETQ@mail.gmail.com>
Date: Sun, 21 Jul 2013 09:28:30 -0700
Message-ID: 
 <CA+2rt40tfLY_iQ=6U1HbU9a_+i4gJrCiobGV2VFvE5Zd3Sps_Q@mail.gmail.com>
Subject: Re: Regarding the BLOCKER bug Cloudstack-3589 VM created from VPC
 network is not getting IP
From: Sheng Yang <sheng@yasker.org>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Cc: "dhoogland@schubergphilis.com" <dhoogland@schubergphilis.com>,
	Alena Prokharchyk <Alena.Prokharchyk@citrix.com>,
	Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
Content-Type: multipart/alternative; boundary=bcaec519646ddc912604e2080ce3

--bcaec519646ddc912604e2080ce3
Content-Type: text/plain; charset=ISO-8859-1

Sorry, the integration test of VPC has been failed for quite some time, I
just found this issue after fixing some other issues in the integration
test...

--Sheng


On Sun, Jul 21, 2013 at 9:23 AM, Daan Hoogland <daan.hoogland@gmail.com>wrote:

> I am happy to redo the work with a different approach, but it did not break
> integration last week, did it? So a newer patch needs to be reverted, no?
> The problem might be cumulative due to more then one commit, in which case
> a role forward might be the quickest way to go.
>
>
> On Sun, Jul 21, 2013 at 6:15 PM, Sheng Yang <sheng@yasker.org> wrote:
>
> > 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 <daan.hoogland@gmail.com
> > >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 <sheng@yasker.org> 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:
> > > >
> > > > <quote>
> > > > except-interface=eth1
> > > > except-interface=eth2
> > > > except-interface=lo
> > > > </quote>
> > > >
> > > > 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 <
> > daan.hoogland@gmail.com
> > > > >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 <sheng@yasker.org>
> > 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 <sheng@yasker.org>
> > > 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.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--bcaec519646ddc912604e2080ce3--